All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.