I've been trying to stay out of this, but the above paragraphs are so
ridiculously erroneous - particularly "will break practically
everything" - that I have to respond.
If the user visible dev_t is changed, the new representation has to
obey a few simple constraints and all the system calls that pass
device numbers in and out of the kernel have to get new versions.
That's stat, fstat, lstat, mknod, and maybe a couple of ioctls.
99% of user space code will not notice AT ALL.
0.9% of user space code gets dev_t values from stat() and compares
them for equality. It will break mildly until the C library is
updated to use the new system calls. (Note glibc's dev_t is already
64 bits wide.) For example, a program has a chance of mistakenly
thinking that two files on different mounted filesystems - say, one on
device #3,2 and one on #258,2 - are the same file.
0.1% or less of user space code examines the structure of a device
number. It will not be able to handle devices with major or minor
numbers >255 until it is recompiled against a C library that has been
updated to understand the new device numbers. mknod(8) won't be able
to create them, ls -l output will be incorrect, and that's about it.
No program that wasn't written by a moron will need to be modified to
handle large dev_t.
David Parsons will have to put a larger dev_t into libc4.
---This is all completely orthogonal to devfs. Very few programs would notice or care if the concept of device special files disappeared entirely, as long as st_dev was some sort of cookie that distinguished files with the same inode number on different filesystems.
Contrariwise, if you deleted the device-file code from every file system except UFS, had a micro UFS partition you mounted as /dev, and left dev_t alone, again essentially nothing would notice.
zw
- 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/