Re: Device Naming under Linux [Long]

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Tue, 21 Apr 1998 14:55:05 +1000

L. Adrian Griffis writes:
> > From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU>
> >
> > 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.

Well, 24 bits for minor numbers is *just* enough. From the devfs
README for SCSI devices:

host 6 bits (say up to 64 hosts on a really big machine)
channel 4 bits (say up to 16 SCSI buses per host)
id 4 bits
lun 3 bits
partition 6 bits
TOTAL 23 bits

This leaves you with just one bit to play with. As long as nothing new
comes in the SCSI spec, we should be OK...

But you are still limited to 8 bits for the major number. devices.txt
tells me that half the available numbers are "in use" (either
officially allocated or reserved for local/experimental use). How long
before we hit the 8 bit limit?

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

Increasing the size of dev_t is going to cause compatibility problems
with C libraries: it's not "just" a filesystem change. With devfs you
don't need to increase major and minor sizes.

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

I don't understand what you're driving at here. If some new file
permissions scheme were to be introduced, I don't see why it would be
any harder to support it with devfs than with ext?fs.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu