Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

Theodore Y. Ts'o (tytso@mit.edu)
Fri, 7 Aug 1998 20:15:08 -0400


Date: Fri, 7 Aug 1998 10:58:18 -0400 (EDT)
From: "Andrew J. Anderson" <andrew@db.erau.edu>

Similarly, dev_fs may provide the groundwork for the next "great thing",
perhaps the idea that Ted came up with re: volume names (which being a
former NetWare admin *does* appeal to me greatly). But the simple fact is
that dev_fs is here today, Ted's idea is not.

Actually, I released code that works for ext2 and FAT partitions; it
just doesn't know how to read volume labels for NTFS and ISO9660 drives
yet. But despite its limited number of filesystems which it
understands, it is here today in a form which may be useful for quite a
few folks.

Certainly, using volume labels is IMO far better than a silly name like
c0s1d4t6 or whatever ---- first of all, the volume name has semantic
meaning to the user, and secondly, it works even if you remove the JAZ
cartridge from one drive and put it into another drive, since the name
follows the filesystem, not the SCSI id.

I wasn't expecting Linus to put devfs in, since at least theoretically
we were in code freeze, but Linus has indicated that he might make an
exception for devfs; that's his perogative, since he's the Great
Dictator. :-) My opinion is still that devfs is an hack, though, and
that there are far better solutions available to folks.

(Note that since my solution doesn't require kernel modifications; it's
a loadable module which will work without modifications, TODAY, under a
linux 2.1 kernel.)

Fundamentally, I disagree with Richard Gooch that persistence is a "side
issue". Being able to assign groups and permissions is a fairly
fundamental part of /dev, and how system administrators allow who's
allowed to access a modem, a tape drive, a printer, etc. To make it an
afterthought in the design is in my opinion a big mistake, and it's one
of the reasons why I consider devfs a hack. Running tar on /devfs at
shutdown time is at least ten times as ugly as indirecting through a
lookup table for resolving major/minor devifs numbers. :-)

- Ted

-
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.altern.org/andrebalsa/doc/lkml-faq.html