devfs
[Top] [All Lists]

Re: devfs and USB

To: devfs@xxxxxxxxxxx
Subject: Re: devfs and USB
From: Johannes Erdfelt <jerdfelt@xxxxxxxxxxx>
Date: Mon, 17 Apr 2000 19:45:08 -0700
In-reply-to: <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca>
References: <20000328144530.Z860@valinux.com> <200004130453.e3D4r9F04628@vindaloo.ras.ucalgary.ca> <20000413115522.W14581@valinux.com> <200004152255.e3FMtG425171@vindaloo.ras.ucalgary.ca> <20000417120035.Y14581@valinux.com> <200004180236.e3I2aSo27324@vindaloo.ras.ucalgary.ca>
Sender: owner-devfs@xxxxxxxxxxx
On Mon, Apr 17, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> > > Ah, I think the light begins to dawn. I noted how in your patch you
> > > were using the DEVFSD_NOTIFY_REGISTERED and DEVFSD_NOTIFY_UNREGISTERED
> > > events. I was thinking that you were just creating fake events (by
> > > trying to write to the /dev/.devfsd pipe yourself somehow) or by
> > > registering fake device entries. That's why I've been negative, as
> > > such a scheme would be a real abuse of devfs. Far cleaner to implement
> > > your own protocol and daemon.
> > >
> > > However, I'm now guessing that you register a real device entry (in
> > > other words, it's connected to a driver (in this case, the USB
> > > subsystem driver) and is the only way for user-space to talk to the
> > > device) in the USB subsystem, and you want devfsd to install the best
> > > driver and (somehow) attach that driver to the device entry. And you
> > > make the attachment using an ioctl(2) on the newly registered device
> > > driver.
> > > 
> > > Furthermore, the attached device driver doesn't register a new device
> > > entry, the user must use the "generic" device entry created by the USB
> > > subsystem, except that it's not quite so generic once a driver gets
> > > attached.
> > > 
> > > Is this a reasonable description of what happens and what you want to
> > > do?
> > 
> > This is exactly what is being done.
> 
> Hm. But is it quite like this? If you have a device with multiple
> interfaces, and multiple drivers get loaded, what's the interface to
> user-space? Do you have a single device node and multiplex that, or do
> you actually present multiple device nodes, with each hooked to a
> single driver?

Right now, we have one node for the entire device and everything is done
via ioctl()'s. This isn't a good idea. I have a solution which splits
out everything into separate nodes, but I'm still implementing some of
it.

> I have another question too: from what context do you call
> <devfs_register>? I.e. interrupt, tasklet or process?

Kernel thread. It's called khubd and it handles all insertions and removals
of all USB devices.

JE


<Prev in Thread] Current Thread [Next in Thread>