On Mon, Apr 17, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> Johannes Erdfelt writes:
> > On Mon, Apr 17, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> > > 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?
This the same interface that user level drivers will use.
We could use a central node/pipe, but we're gonna create the device nodes
anyway, so might as well use them.
It could work either way. I'm not particular attached to either method.
> > > 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>
We originally had it like that, but it's a whole lot cleaner and easier to
code the hub control code when you can block until on a wait_queue or
something similar.
There's just too much state and creating weird asynchronous code to handle
it all was more trouble than it's worth.
JE
|