Johannes Erdfelt writes:
> 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.
Yeah, I think separate device nodes would be cleaner. Now, if you do
that, do you still need the user-space daemon talking via the
dynamically created "generic" device node? Or can you just talk via a
central device node for all USB devices?
The PCMCIA code, for example, just as a central node/pipe which
cardmgr talks to. Why can't you do it like that?
> > 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.
<wipes brow>
Whew. That's a relief. At the moment, device registrations have to be
done from a process context. I've left this issue open. I may decide
to support this from interrupt contexts, but that would make things a
lot harder, and I'm undecided on whether that's a good idea.
</wipes brow>
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|