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
On 2014-04-15 09:42, Emmanuel Colbus wrote:
> 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?
>
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)
> 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.
Le 15/04/2014 17:06, One Thousand Gnomes a ?crit :
>> 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.
> 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.)
> 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.
>
> 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
> 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
Le 15/04/2014 17:02, Austin S Hemmelgarn a ?crit :
> On 2014-04-15 09:42, Emmanuel Colbus wrote:
>> 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?
>>
>
> 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)
>
I see... Well, I think I'm going to take 254/0 for this then.
Thank you!
Emmanuel
On Tue, Apr 15, 2014 at 05:32:41PM +0200, Emmanuel Colbus wrote:
> > 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!
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
Le 15/04/2014 22:19, Theodore Ts'o a ?crit :
> On Tue, Apr 15, 2014 at 05:32:41PM +0200, Emmanuel Colbus wrote:
>>> 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!
>
> 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...)
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