Messages in this thread | | | Date | Mon, 20 Apr 1998 19:34:05 -0500 | From | "L. Adrian Griffis" <> | Subject | Re: linux-kernel-digest V1 #1849 |
| |
owner-linux-kernel-digest@vger.rutgers.edu wrote: > From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> > Date: Mon, 20 Apr 1998 22:18:06 +1000 > Subject: Re: Device Naming under Linux [Long] > > Robert de Bath writes: > > > 2) user space symlinks are usually a bad idea. > > Agreed > > > > > 3) devfs > > I really dislike this, it feels a lot like putting /dev onto a ramdisk > > with a special program to copy stuff from /proc and gives me a really > > fragile feeling. > > On the contrary, devfs is *quite* robust and clean. And it solves the > problem of major&minor sizes once and for all: you don't need them at > all! Devfs is not just /dev in a ramdisc. Read the README on it to see > why it's a good idea. Without devfs you need a sequence of hacks to > solve some of the problems.
HPUX and AIX both use 32 bit device numbers, with 8 bits for the major number and 24 bits for the minor numbers. While there's a lot to dislike about AIX in particular, this particular aspect of both of these two systems answers many of the problems I've seen discussed in this list. It's easy to code the SCSI host adapter, the target ID, LUN, and slice in the device numbers, and still have room for a few options.
This would, of course, mean a new version of the filesystem, and that seems to me to be an unwanted complication in itself. But isn't there already a discussion of a filesystem with information about some new capabilities stored in it? As long as we are considering a new kind of filesystem, why not add two bytes to the minor device number?
Personally, I think any complications in the permissions of a filesystem might prove useful in the administration of device file permissions anyway. It seems that we would either not have the option to take advantage of this additional permissions mechanism in a devfs, or we would risk unexpected problems with these device file permissions if the bootup initialization mechanism we chose failed to operate properly.
My $.02 worth.
-- --- L. Adrian Griffis - KE6CSX - adrian@idir.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |