public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Emmanuel Colbus <ecolbus@manux.info>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC][5/11][MANUX] Kernel compatibility : major/minor numbers
Date: Tue, 15 Apr 2014 17:32:41 +0200	[thread overview]
Message-ID: <534D5119.8050701@manux.info> (raw)
In-Reply-To: <20140415160626.322e24ee@alan.etchedpixels.co.uk>

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

  reply	other threads:[~2014-04-15 15:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 13:42 [RFC][5/11][MANUX] Kernel compatibility : major/minor numbers Emmanuel Colbus
2014-04-15 15:02 ` Austin S Hemmelgarn
2014-04-15 17:39   ` Emmanuel Colbus
2014-04-15 15:06 ` One Thousand Gnomes
2014-04-15 15:32   ` Emmanuel Colbus [this message]
2014-04-15 15:40     ` One Thousand Gnomes
2014-04-15 20:19     ` Theodore Ts'o
2014-04-15 20:58       ` Emmanuel Colbus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=534D5119.8050701@manux.info \
    --to=ecolbus@manux.info \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox