Johannes Erdfelt writes:
> 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.
Why are you creating these "generic" device nodes anyway?
What I'm basically trying to work out is why you can't have a central
pipe which the daemon talks to, and when drivers attach to the
interface, the daemon talks to the USB subsystem and does a mknod(2)
as appropriate. This is the kind of argument the anti-devfs crowd will
make.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|