Re: Devfs, was Re: Migrating to larger numbers

david parsons (o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s)
9 Jun 1999 15:13:08 -0700


In article <linux.kernel.E10rWm2-0008Hx-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> 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

What sort of infrastructure will you have to do to make it work,
though?

If it becomes a case where the driver has to publish some information
in /proc, so a user-level script can massage it and rebuild /dev on
the fly, it's a LOT easier to just use devfs and have a similar
script rebuild /dev on the fly. In the case where you don't like
what devfs uses as device names or any of the other (IMO: bizarre)
reasons against devfs, it can simply be used as a database to
populate the real /dev directory, by mounting, mining, then closing
up shop and waiting for the Environmental Safety folks to condemn it.

And in cases where you don't have space to fit the user-level
infrastructure (like a single-floppy installer/repair setup), having
a /devfs gives back the blocks used by /dev, plus greatly simplifies
the task of enumerating devices on the system. In this case you're
also still using it as a database, but the 4-8k back for dumping the
old static /dev is just a little something extra.

____
david parsons \bi/ I guess you'd call this ``data mining''
\/

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