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