Johannes Erdfelt writes:
> On Sat, Apr 15, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> > 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.
[...]
> 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.
Fair enough. That's about what I figured.
> > > 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.
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?
I have another question too: from what context do you call
<devfs_register>? I.e. interrupt, tasklet or process?
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|