dwguest@win.tue.nl (Guest section DW) writes:
|> (But a device is identified by the device number (a dev_t).
|> Roughly speaking it is never the business of user space
|> dividing this up into major and minor. So, every user space program
|> that uses the definitions of MAJOR and MINOR is broken.
That is true, but in a difference sense. The correct way is to use
the major/minor/makedev functions. No need to poke into the kernel
headers.
|> In practice however there are a few programs that rely
|> on a particular structure, like mknod, or ls, or lilo.)
Wrong. None of these programs rely in any way on a particular structure
of dev_t. They use the major/minor accessor function and the makedev
contructor function. How the values are encoded in dev_t values is
completely opaque to them.
I meant something different from what you read into my words.
In particular, I also regard every user space program that
uses the major/minor accessor function and the makedev
contructor function as broken.
There is very little difference between getting a random definition
of MAJOR from <linux/kdev_t.h> or one of major from <sys/sysmacros.h>.
The device number is just a cookie, something without internal structure,
and programs that try to find major, minor, subminor part are broken.
Interfaces that use internal structure as input are broken.
Thus, the mknod program is broken (but the mknod system call is not).
Interfaces that use internal structure as output are broken.
Thus, the ls program is broken.
Programs like lilo that use MAJOR and MINOR (yes, you say `Wrong', but
I find MAJOR, MINOR as included from <linux/fs.h> in the lilo-21 source)
are broken. The action of a program should not in some subtle way
depend on the device number of the disk. This has caused strange errors.
Every now and then I run a system with large device numbers.
Roughly speaking all is well, but all programs that try to understand
the inner structure of device numbers require some special attention.
They want to know what they need not, and it is annoying.
Andries
-
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/