Messages in this thread | | | Date | Tue, 8 Jun 1999 02:12:50 -0400 (EDT) | From | "Albert D. Cahalan" <> | Subject | Re: Migrating to larger numbers |
| |
H. Peter Anvin writes: > Alan Cox wrote:
>>> I suggest, as you say, a 32:32 split (it's simple). >> >> 64bit dev_t's are going to cause some real problems. I would suggest >> you try passing a 64bit dev_t over NFS - especially to non unix >> clients before you do this. >> >> If you go to a 64bit dev_t you will have to do hackish horrors for >> NFS support even Linux to Linux. Stay with a 32bit dev_t, supporting >> more device files than we can create 1 a second within our epoch is crazy > > Not really... some devices have a legitimate need for a sparse minor > number space. I'd be interested in how HP/UX deals with this; they've > had a fairly large dev_t for aeons.
HP/UX was using 8:24 last I heard, with /bin/ls using hex.
The sparse minor argument is mostly garbage now. It made perfect sense when wide SCSI (15 devices) was the worst case. Now we can have tree-like systems that need infinite bits.
It is easy to use up 64 bits. Look here:
8 node 4 bus 4 bus 4 slot 8 port (place where a cable connects to a card) 8 port (on hub) 8 port (on hub) 8 port (on hub) 8 port (on hub) ... ... 8 LUN 8 partition (native) 8 partition (nested)
If you have a solution to the above, it can be used to fit everything into 32 bits. I suggest dynamic numbers with devfs, but that need not be the only way to solve the problem.
If you have userspace generating /dev entries as needed (to avoid terabytes of inodes), then you might as well use dynamic numbers. You already lost the advantage of static number assignments.
OSF/1, Digital UNIX, and Tru64 all :-) use 12:20 device numbers. That would be nice. It allows static allocation for the easy cases while not causing NFS trouble and general bloat on ia32.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |