> orc@pell.portland.or.us (david parsons) said:
> > In article <linux.kernel.199910141142.IAA10452@pincoya.inf.utfsm.cl>,
> > Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> > >orc@pell.portland.or.us (david parsons) said:
>
> > >[...]
>
> > >> I think there may be a bit of confusion here. The PC-style ports
> > >> already exist, and Linux already handles them. If I build a modular
> > >> kernel (which I do), the current version of Linux will already do the
> > >> fbm needed to load the drivers and give me access. If I use a
> > >> devfs, current 2.3.x's will do the fbm needed to load the drivers and
> > >> give me access without any changes to userland. But if I use devd as
> > >> described in recent email on the kernel list, I either have to have
> > >> the device nodes already installed or I have to bloat my kernel with
> > >> the detection parts of the drivers or I have to build the drivers
> > >> into the kernel.
>
> > >The described kernel will notify devd to create the nodes when they show
> > >up, i.e., on boot or when the device is plugged in.
>
> > How?
> >
> > Until I insmod the parallel port driver, the kernel doesn't know
> > that there are any parallel ports around.
>
> Because it doesn't check before.
>
> > >Any dynamic /dev will
> > >have to include this exact functionality somehow,
>
> > Perhaps it would be a good idea if you wasted the five minutes
> > necessary to look at Richard Gooch's code before you commented
> > further on it.
>
> Look, to find out if the foo device is present, you _have_ to check
> somehow. No way around that. I somehow seriously doubt devfs does some
> mindreading trick here.
Actually, in a way it does. It can be setup so that if you attempt to
access a parallel port device it then goes and insmods the driver. this
allows it to not do a scan of everything to start.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/