Hi, Johannes. I've also Cc'ed the devfs list, so interested parties
can comment if they want. I'm assuming you won't mind.
> > > What I would like to do is provide a write() function for the devfsd
> > > pipe/device (/dev/.devfsd). And then allow device drivers (or in my
> > > case, the USB subsystem) specify a flag while registering the device
> > > that it would like devfsd to select a driver for it to use.
> > >
> > > When devfsd finishes it's logic and comes up with a driver, it
> > > write()'s it back through the devfsd pipe/device and devfs will
> > > store the information for the subsystem to retrieve.
> >
> > Why write back to the USB subsystem? Why not load the device driver
> > directly?
>
> Well, you need to bind a driver to a device. You may have a dozen
> drivers loaded, and 2 may be able to run the device correctly, but
> one can run it better than the other.
OK, I see now.
> The issue of selecting a driver is complicated and best left to
> userspace. Take a look at my example below.
Yes, that's fair enough.
> > Why do you want to overload devfs/devfsd?
>
> Since I wrote this email, I've changed my mind slightly. Some of what I said
> above is not the best way of doing (like you've noticed). What i'm going to
> say below will differ in some instances from what I said in the original
> email.
>
> I don't want to overload devfs, I want to overload devfsd. The patch
> implements exactly what I want do. But, I'll explain it quickly for
> you here.
OK, I'm a lot happier about hearing that. Changes to devfs for a
specific driver subsystem are to be avoided. Strongly.
[...]
> We need a userspace daemon which tracks device insertion and removal
> events and finds all of the appropriate information on the device
> and chooses the correct driver to run the device. It then loads the
> driver, if it's not loaded already. It then configures the device by
> selecting the appropriate configuration and alternate setting. Then
> it binds the driver to the device.
This is all fine.
> 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.
> 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?
> The example above is a quick example and gets much more complicated
> when you factor in multiple interfaces and configurations, power
> budgeting, bandwidth budgeting, etc. It's a complicated decisions
> making process.
That's fine. It's clear this needs to be done in user-space.
> 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?
> 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?
> 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.
> 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.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|