Kernel compatibility : major/minor numbers
RFC 5/11 Kernel compatibility : major/minor numbers
Now, back to the filesystem...
In order to associate devices to their files, the Linux kernel uses their major and minor numbers. However, mine doesn't; instead, I've attributed myself a single group of values (major=0, minor=0, for both character-mode and block-mode special files), with the meaning (for the userspace) "you cannot identify the content of this file based on its major and minor numbers".
As for my kernel, there is a syscall to associate such files with their proper peripherals (asper(2)), after which it internally identifies them using their inode and partition numbers; as for userspace, it has no choice but to use their names, as usual.
Do you have any objection to my taking of these values?
Emmanuel
Quoted 9 lines · Emmanuel Colbus
Now, back to the filesystem...
In order to associate devices to their files, the Linux kernel uses their major and minor numbers. However, mine doesn't; instead, I've attributed myself a single group of values (major=0, minor=0, for both character-mode and block-mode special files), with the meaning (for the userspace) "you cannot identify the content of this file based on its major and minor numbers".
Quoted 7 lines
As for my kernel, there is a syscall to associate such files with their proper peripherals (asper(2)), after which it internally identifies them using their inode and partition numbers; as for userspace, it has no choice but to use their names, as usual.
Do you have any objection to my taking of these values?
According to Documentation/devices.txt:
0 Unnamed devices (e.g. non-device mounts)
0 = reserved as null device number
Based on this, I would say that you are probably better off using one of the local use numbers (60-63 and 250-254 are reserved for local and experimental use)
Quoted 18 lines · Austin S Hemmelgarn
Quoted 9 lines · Emmanuel Colbus
Now, back to the filesystem...
In order to associate devices to their files, the Linux kernel uses their major and minor numbers. However, mine doesn't; instead, I've attributed myself a single group of values (major=0, minor=0, for both character-mode and block-mode special files), with the meaning (for the userspace) "you cannot identify the content of this file based on its major and minor numbers".
Quoted 7 lines
As for my kernel, there is a syscall to associate such files with their proper peripherals (asper(2)), after which it internally identifies them using their inode and partition numbers; as for userspace, it has no choice but to use their names, as usual.
Do you have any objection to my taking of these values?
Quoted 8 lines
According to
Documentation/devices.txt:
0 Unnamed devices (e.g. non-device mounts)
0 = reserved as null device numberBased on this, I would say that you are probably better off using one of the local use numbers (60-63 and 250-254 are reserved for local and experimental use)
I see... Well, I think I'm going to take 254/0 for this then.
Thank you!
Emmanuel
Quoted 6 lines
In order to associate devices to their files, the Linux kernel uses their major and minor numbers. However, mine doesn't; instead, I've attributed myself a single group of values (major=0, minor=0, for both character-mode and block-mode special files), with the meaning (for the userspace) "you cannot identify the content of this file based on its major and minor numbers".
If you are using the Linux ABI then you'll hit cases (in particular tty cases) where the ABI/API knows about major/minor numbers. In addition the standards and common sense together pretty much imply that you need each device to at least have a unique identifier.
Finally you need major/minor numbers to NFS serve to a diskless client.
Most Linux device numbering beyond that is basically dynamic so it probably does't matter that much for things you concoct - providing in som cases your /proc table of major numbers is right.
Quoted 9 lines · One Thousand Gnomes
Quoted 6 lines
In order to associate devices to their files, the Linux kernel uses their major and minor numbers. However, mine doesn't; instead, I've attributed myself a single group of values (major=0, minor=0, for both character-mode and block-mode special files), with the meaning (for the userspace) "you cannot identify the content of this file based on its major and minor numbers".
If you are using the Linux ABI then you'll hit cases (in particular tty cases) where the ABI/API knows about major/minor numbers.
Well, in fact, my kernel *can* handle major and minor numbers. That is, if you tell it "mknod /dev/efjkb c 8 6" , you'll actually get a device file with major/minor numbers 8/6. But then, the kernel simply disregards these values and waits for userspace to specify it what this device means. So it's completely possible to emulate Linux's behaviour with it.
Quoted 4 lines
In addition the
standards and common sense together pretty much imply that you need each device to at least have a unique identifier.
Why is it? I mean, as far as userspace is concerned, they do have a unique identifier : their name. How would it be problematic that the software is unable to confirm that /dev/null is actually connected to the usual /dev/null kernel driver? I mean, it's supposed to trust the OS and its admin to have done their job properly, not second-guess them!
(My idea behind this is to allow lying, for example by allowing the sysadmin to fake the content of, say, /dev/random, to an application he wants to test, or even deliberately sabotage. So, in my OS's logic, there's nothing wrong with emulating Linux's major/minor device identifiers, but of course, their reliability will be in the sysadmin's hands, so I thought I could simply make this clear by using explicitely unreliable identifiers.)
Quoted 1 line
Finally you need major/minor numbers to NFS serve to a diskless client.
Not a problem, but of course, the distant client will have the ability to connect anything it wants to any device it wants.
Quoted 5 lines
Most Linux device numbering beyond that is basically dynamic so it probably does't matter that much for things you concoct - providing in som cases your /proc table of major numbers is right.
Ah... Uhhh... I've not implemented any such table, so I guess it's currently not. Whoops...
Emmanuel
Quoted 2 lines
Why is it? I mean, as far as userspace is concerned, they do have a unique identifier : their name. How would it be problematic that the
No - a name is never a unique identifier in a Unix system. The fundamental object is the file handle. If I want to be able to answer the question
"are these two file handles pointing to the same device"
I need the major/minor to do so. Even if I know the name I don't know if two opens of the same name produced references to the same object, because another process may have changed it under me.
Most code doesn't care. You can happily replace /dev/null with something else (or accidentally make it a file and then a year later wonder why your disk is full).
Names are very much second class citizens. An object can have a file handle without a name, or with many names
Alan
Quoted 10 lines · Emmanuel Colbus
Quoted 4 lines
In addition the
standards and common sense together pretty much imply that you need each device to at least have a unique identifier.Why is it? I mean, as far as userspace is concerned, they do have a unique identifier : their name. How would it be problematic that the software is unable to confirm that
/dev/nullis actually connected to the usual/dev/nullkernel driver? I mean, it's supposed to trust the OS and its admin to have done their job properly, not second-guess them!
Backup programs will very often assume that if after two files, if stat(2)'ed, have the same st_ino and st_dev (which is a major/minor pair), then they are both hard links to the same underlying files.
There are also programs that will relying on st_dev for the purpose of honoring find -xdev, and there are also programs that may try to do intelligent things by assuming that st_dev and st_ino togehter will uniquely name the same content. This gets tricky for remote file systems to get right, but file systems that don't at least try to get this right can end up triggering some very hard to debug userspace bugs. Transarc's Andrew File System (AFS) would occasionally break this property, back in the late 1990's, and it was the cause of Much Hilarity (except on the part of the programmers who had to figure out why certain programs were stuck looping forever while trying to analyze a long AFS pathname...)
- Ted
Quoted 16 lines · Theodore Ts'o
Quoted 10 lines · Emmanuel Colbus
Quoted 4 lines
In addition the
standards and common sense together pretty much imply that you need each device to at least have a unique identifier.Why is it? I mean, as far as userspace is concerned, they do have a unique identifier : their name. How would it be problematic that the software is unable to confirm that
/dev/nullis actually connected to the usual/dev/nullkernel driver? I mean, it's supposed to trust the OS and its admin to have done their job properly, not second-guess them!Backup programs will very often assume that if after two files, if stat(2)'ed, have the same
st_inoandst_dev(which is a major/minor pair), then they are both hard links to the same underlying files.
Quoted 11 lines
There are also programs that will relying on
st_devfor the purpose of honoring find -xdev, and there are also programs that may try to do intelligent things by assuming thatst_devandst_inotogehter will uniquely name the same content. This gets tricky for remote file systems to get right, but file systems that don't at least try to get this right can end up triggering some very hard to debug userspace bugs. Transarc's Andrew File System (AFS) would occasionally break this property, back in the late 1990's, and it was the cause of Much Hilarity (except on the part of the programmers who had to figure out why certain programs were stuck looping forever while trying to analyze a long AFS pathname...)
Yes, in fact, I do respect the unicity of the st_dev field, so all these assumptions work. The only thing I'm doing is violating the assumption that, if a file has a certain major and minor numbers according to its st_dev field, then there is a special block file in /dev that has the same major and minor numbers and that corresponds to the storage peripheral where this file is stored.
Emmanuel