Linux-kernel mailing list archive 2000-15,: Re: devfs - why not ?

# Re: devfs - why not ?

Horst von Brand (vonbrand@inf.utfsm.cl')
Thu, 13 Apr 2000 10:47:20 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Linus Torvalds: "Re: pcmcia tulip.o [was What to do with 3c59x.c?]"
- Previous message: Andrea Arcangeli: "Re: [PATCH] Simple Page Coloring [fixed] (2.3.99pre3 diffs)"
- Maybe in reply to: Robert Kaiser: "devfs - why not ?"
- Next in thread: Richard Gooch: "Re: devfs - why not ?"
- Next in thread: H. Peter Anvin: "Re: devfs - why not ?"
- Reply: Richard Gooch: "Re: devfs - why not ?"

Peter Samuelson <peter@cadcamlab.org> said:
> [Horst von Brand <vonbrand@sleipnir.valparaiso.cl>]
> > No. How do you load a module for /dev/foo117, when /dev/foo117
> > doesn't currently exist?

> Actually with devfs it's really easy. If user space tries to open
> /dev/foo117, and it doesn't already exist, this will generate a devfsd
> event. Then devfsd can look in its config file and call modprobe.

The question was why devfsd was needed at all...

[...]

> > This is elegantly solved in the traditional case with just a device
> > file created before use, major/minor (more generally, device id) tell
> > the kernel what module to ask for.

> You forgot the part about encoding the major (and possibly minor)
> numbers into /etc/modules.conf.

Or into /etc/devfsd.conf. Same thing.

> Here's the real difference. Say you compile serial.o as a module:
>
> # modules.conf: if we get a request for a character device on major
> # number 4, have modprobe load serial.o
> alias char-major-4 serial

> # devfsd.conf: if someone tries to stat or open /dev/tts or
> # /dev/tts/*, have devfsd run modprobe to load serial.o
> LOOKUP tts EXECUTE modprobe -k serial

In the case above I'm using extant mechanism (kmod has to stay for the
later one to work). For modules.conf I need the association major == 4 -->
serial; in devfsd.conf I need the association /dev/ttys/* --> serial. Same
thing, different syntax. But more mechanism, which is pure overhead as it
solves nothing and introduces new problems (non-persistence). Not just
bloat, ballast.

[...]

> Wait -- don't chown/chmod/mknod also generate devfsd events? Why can't
> devfsd take those events and operate on a parallel directory tree? And
> then use that parallel tree to chmod/chown next time the device inserts
> itself, i.e. after insmod or reboot. (Remember, devfsd is notified on
> every file creation, if it cares.) No tar kludge involved.

Why are you then building all this crap on top of the parallel tree in the
first place?!

> I could have sworn this was Richard's idea, not mine. devfsd, properly
> implemented, can solve a *lot* of these problems. If the current
> devfsd is a WIP, don't blame it on devfs design problems.

devfsd, working on a on-disk device tree does solve the problems rather
nicely IMHO. devfs is a horrible kludge, and seeing Linus include that in
his tree makes me seriously doubt his taste this one time. And the devfsd
idea is Linus's, AFAIKT.

    --
    Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
    Departamento de Informatica                     Fono: +56 32 654431
    Universidad Tecnica Federico Santa Maria              +56 32 654239
    Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

    -
    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/

- Next message: Linus Torvalds: "Re: pcmcia tulip.o [was What to do with 3c59x.c?]"
- Previous message: Andrea Arcangeli: "Re: [PATCH] Simple Page Coloring [fixed] (2.3.99pre3 diffs)"
- Maybe in reply to: Robert Kaiser: "devfs - why not ?"
- Next in thread: Richard Gooch: "Re: devfs - why not ?"
- Next in thread: H. Peter Anvin: "Re: devfs - why not ?"
- Reply: Richard Gooch: "Re: devfs - why not ?"