lkml.org 
[lkml]   [1998]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.535 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site