Linux-kernel mailing list archive 1999-23,: Re: Devfs, was Re: Migrating to larger numbers

# Re: Devfs, was Re: Migrating to larger numbers

Richard Gooch (rgooch@atnf.csiro.au)
Wed, 9 Jun 1999 11:26:07 +1000

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Linus Torvalds: "Re: [RFC-PATCH] nfs client enhancements"
- Previous message: Alan Cox: "Re: Devfs, was Re: Migrating to larger numbers"
- In reply to: Alan Cox: "Re: Devfs, was Re: Migrating to larger numbers"
- Next in thread: Nathan Hand: "Re: Devfs, was Re: Migrating to larger numbers"
- Reply: Nathan Hand: "Re: Devfs, was Re: Migrating to larger numbers"

Alan Cox writes:
> > Anything specific? It provides all kinds of neat tricks. For example,
> > if all your CD-ROMs devices are unloaded and you have module
> > autoloading, then to find all CD-ROMs on the system, you just do:
> > opendir ("/dev/ide/cd");
> > loop;
> > opendir ("/dev/sr");
> > loop;
> >
> > and your directory scanning code knows that each and every entry
> > (besides "." and "..":-) is a Genuine CD-ROM[tm] that actually exists
> > on your system. No need to process a large directory, speculatively
> > opening device nodes to see if there's some hardware behind them.
>
> I just wonder if this shouldnt be generated by userspace, by
> ensuring the right helpful info is in /proc etc

Yeah, I keep hearing arguments along this line. I don't think they
hold up, though, because:
- for each cool thing you add another hack to the kernel to support it
(OK, not always, but the trend is there)
- total system complexity goes up as you have a growing collection of
daemons and scripts to do these new cool things
- you miss the efficiency of devfs
- it makes it much easier to handle read-only or non-Unix root FSes.

Devfs is a single, simple framework that allows you to do do a whole
raft of cool things without having to add a patch for each new trick.
Devfs is extremely lightweight (about a few pages of code and a few
pages of data on an average system). The pages you save by not having
devfs you lose in having a bunch of clever daemons instead (we can't
avoid paying for kernel stake space).

Also, since this debate started because of talk about increasing
device number size, let me point out that with devfs can save having
to store the two tables of major numbers (chr and blk), which are
going to grow somewhat. I admit that would require further changes,
which I've avoided in order to have minimal impact.

However, with devfs you can definately avoid the lookups into the
major tables. Right now that's fast because they're simple arrays. If
we go to 12 bit majors (or more), we're going to want to set them up
as lists of some kind. And that means some kind of searching/hashing.
And that's all for the benefit of finding our fops. Devfs completely
avoids this overhead.

Regards,

Richard....

-
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: [RFC-PATCH] nfs client enhancements"
- Previous message: Alan Cox: "Re: Devfs, was Re: Migrating to larger numbers"
- In reply to: Alan Cox: "Re: Devfs, was Re: Migrating to larger numbers"
- Next in thread: Nathan Hand: "Re: Devfs, was Re: Migrating to larger numbers"
- Reply: Nathan Hand: "Re: Devfs, was Re: Migrating to larger numbers"