Messages in this thread | | | Date | Wed, 22 Apr 1998 12:23:26 +1000 | From | Richard Gooch <> | Subject | Re: Device Naming under Linux [Long] |
| |
L. Adrian Griffis writes: > Richard Gooch wrote: > > > > L. Adrian Griffis writes: > > > 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 > > So you're suggesting 10 bits, in effect, to select a SCSI bus? That's > certainly more than I would have chosen. And I've seen a lot of disks > with 16 slot partition tables, but none so far with 64 (six bits to > select the partition). Is it just me, here?? Have I lead a sheltered > life, or is this perhaps an overstatement of the number of bits needed > to select a SCSI device?
The world isn't just a PC, you know. Take a look at a large SGI or Sun machine. We have a SGI Power Challenge here (old hat already) which throws around SCSI buses just for the fun of it. You can buy I/O boards for these beasts with something like 24 SCSI channels, as I recall. Linux should support large systems *just as easily* as it supports small systems.
The reason you need to allocate so many bits is because you don't know how the #hosts/#channels breakdown will be done on different machines. Hacking the host and channel number into a single (say 6 bit) value gets us back to the broken /dev/sd{a,b,c,d,e...} naming system we have now. Just for the sake of saving a few 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? > > That's a point worth considering, but take a look at the number of major > device numbers used for tty's alone; Suppose we collapsed all the major > numbers for different tty open blocking policies into one major number, > and expressed all these policies in part of a 24 bit minor number? Are > there any other devices with more than their fair share of major > numbers?
It seems to me that the bulk of major number usage is due to the large amount of hardware we support. Sure, you could do a bit of trimming with the tty driver, but it's not going to save that much in the scheme of things. In my view if we stick with a major&minor scheme, the major number should be at least 16 bits.
> > > 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. > > That's an interresting thought, but the fact is, I've been able to > port all kinds of code between systems with 16 bit and 32 bit dev_t's, > and the only time this difference matters is when that code tries to > interpret information coded into the minor number bits. Code that > does that is pretty system specific anyway. There are standard macros > for separating out the major and minor number and for putting them > back together again. It really doesn't seem to be that big a deal.
What happens when the C library fills in an inode structure and then passes it to the kernel? Or when the kernel fills it in and the C library reads it? libc 5 expects 16 bits for i_rdev. If it gets something different, there will be problems.
> > > 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. > > A filesystem that is stored on disk holds permission and ownership > values through a reboot. One that is generated dynamically has to > employee some more complicated mechanism to assign the desired > values to the dynamically generated entries. What happens if this > more complicated mechanism fails?
There are a variety of simple userspace solutions to solve this. It's not unlike what happens if your machine crashes before your buffers were flushed: both systems are vulnerable to this. I've even written a simple script which can be called at boot/shutdown and via a cron job which saves the permissions across reboots. Easy. It uses that lovely common tool: tar.
If someone wants to write a daemon to do this instead, they are free to do so.
I could even extend devfs to have persistent storage (to disc), but I don't think that's needed: a userspace solution is really easy and pretty much just as "safe" and robust.
> I've notice replies to the effect of "read the devfs FAQ" to some > of the objections to devfs on this list, but I must have missed > the URL for this FAQ. It may be that you have an answer to this > problem is this FAQ, wherever it might be, but my first reaction > to the devfs concept is to worry about complicating the initialization > of something that is so critical to the system's proper operation.
The file Documentation/filesystems/devfs/README contains this kind of information. You get this file as part of the patch. The patch is available from: http://www.atnf.csiro.au/~rgooch/kernel-patches.html
If there is demand, I guess I could put up a FAQ on the WWW without having to download and unpack the patch. Just let me know, people.
> I'm not trying to say that the devfs concept is hopeless; It seems > like an interresting idea to contemplate for some problems we've all > encountered with the current way of managing devices and device names. > But I wonder, sometimes, if your enthusiasm for devfs might be leading > to some slight exaggerations of the shortcomings of some of the > alternatives. Maybe if this thread as a whole were less polarized, > we could take good ideas from all the different factions and turn them > into a real solution.
Well, I try to address the pros and cons in my README, and I try to be fair. If there is a point where you can propose a userspace solution and I haven't included it, I'll be happy to do so. Note however that I also address the issue of how easy a userspace solution is. If something is hard to set up or maintain or understand, I will point that out in the README.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |