Re: [patch] replacing "/dev/root" in /proc/mounts

Andreas Schwab (schwab@suse.de)
11 Oct 1999 12:04:37 +0200


dwguest@win.tue.nl (Guest section DW) writes:

|> From schwab@suse.de Fri Oct 8 18:08:42 1999
|>
|> 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.

Why? This is how device numbers are defined in Unix. Only the way these
numbers are encoded might differ.

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

Device numbers have always been devided in a major number and a minor
number. So ls displays them like this. How can this be broken, if this
is an official part of the Unix API? Read the mknod manpage.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

- 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/