On Sat, Apr 15, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
>
> > There's already a daemon which does this, devfsd. It already gets
> > informed of device insertion and removal and does things with that
> > information.
>
> I just want to be sure that you're not wanting to "hijack" the devfsd
> protocol. In other words, that it really does make sense to use devfsd
> rather than a new daemon (even if you don't modify the protocol). Just
> because it might be convenient (it's there, and it's easy to tap
> into), doesn't mean it should be used.
>
> On the other hand, it doesn't mean devfsd is the wrong approach,
> either. I just want to get a clear picture of what's going on.
I don't want to modify the devfsd protocol. My original intention was to
do so, but upon talking to other people, this was deemed a bad idea.
> > This driver binding is done completely via ioctl()'s on the USB
> > device node, completely bypassing devfs (the kernel portion). The
> > current patch that I've sent makes no changes to devfs (the kernel
> > portion), only to devfsd (the user space portion).
>
> What exactly is this driver binding process? How does it work?
USB devices have multiple interfaces. Each interface is a logical function
of a device.
For instance, I have a webcam which has 2 interfaces. One is the video
camera portion. This uses a vendor defined protocol.
The other interface is for a microphone on the camera. This uses the
USB consortium defined class specification for audio devices.
So, we want the driver specific for the camera to be responsible for the
camera interface, and the audio driver to be responsible for the audio
interface.
It also gets a bit more complicated than this. There are configurations
for a device which modify the number of interfaces and properties for the
device. There are also alternate setttings for interfaces which define
the protocol used, the amount of bandwidth allocated to an interface, etc.
There is an election process which a device goes through to select the
appropriate configuration, drivers for interfaces and alternate setttings
for interfaces.
You can take a look at my explanation at:
http://www.electricrain.com/lists/archive/linux-usb/2000/03/msg00860.html
This explains the proposed algorithm to be used.
> > Another really quick example. I have a digital still camera. The
> > driver for this camera is in userspace in gphoto. We would like to
> > setup the permissions for the device to be accessable by a certain
> > group of users whenever the device is plugged in. However, the USB
> > id, which is what is used to create the device node for the USB
> > device, is arbitrary and can/will differ each time the user plugs in
> > the device.
>
> Why does the ID change? If you plug the same device into the same
> port, why does it change? Do you have unique sequence numbers or
> something?
USB ids are assigned to a device by the host. This is a unique id to
identify the device on the bus and is arbitrarily assigned.
It is assigned in sequential order when USB devices get enumerated on the
bus. It need not be sequential, but that is how it's implemented
currently.
Because of the way USB devices are enumerated, they can be assigned any USB
id and this may change from reboot to reboot depending on the sequence
the devices were plugged in, or the topology of the USB bus.
> > We can use the same code to choose a driver, also track the device
> > and assign the correct permissions to it, no matter what it's device
> > node name of the moment is.
>
> 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.
> > Do you see this a good use for devfsd? Would you accept this feature
> > for inclusion into devfsd?
>
> If it's as I descibed just above, then it makes perfect sense to use
> devfsd.
Great.
> > I'm not asking for the particular patch I sent you to be included,
> > but rather for something like it. I can make changes to the patch,
> > or reimplment it if necessary. I have already changed my local copy
> > to use threads for instance.
>
> I'll implement part of what I'm planning for devfsd modularity so you
> can see how I want this done. I'll send a message to you and the devfs
> list when I've done this. Also, please subscribe to the devfs list by
> sending email to majordomo@xxxxxxxxxxx and "subscribe devfs" in the
> body.
Excellent. I did not realize there was a devfs mailing list. I'll subscribe
now and make sure to open up the discussion for all of those there as well.
JE
|