mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andries.Brouwer@cwi.nl
To: hpa@zytor.com, zippel@linux-m68k.org
Cc: Andries.Brouwer@cwi.nl, linux-kernel@vger.kernel.org
Subject: Re: 64-bit kdev_t - just for playing
Date: Wed, 9 Apr 2003 20:36:32 +0200 (MEST)	[thread overview]
Message-ID: <UTC200304091836.h39IaWE29913.aeb@smtp.cwi.nl> (raw)

> Peter and Andries, I would really appreciate it, if
> you would stop ignoring me

But Roman, I answered a dozen of your letters, and
it seems to me that further letters would only
lead to repetition.

Let me recapitulate.

(i) On dev_t
A dev_t is a number. There are three streams:
mknod sends such a number from user space to the file system,
stat sends such a number from the file system to user space,
open and mount send such a number from the file system to the kernel
where the kernel finds an associated device.

Your questions are about the meaning of this number,
that is, about the third part. What I am doing is only
removing certain restrictions on the size of the number.


(ii) On device naming.
One can handle device naming in the old-fashioned way,
as Unix always did, or one can invent one of many possible
schemes for the future.
This old-fashioned way has a myriad of problems, but it works,
people are used to it and know precisely what the problems are,
and our present software handles it.
These schemes of the future are not yet crystallized out very well,
there are several to choose from, we do not yet know very well
what the problems will be, most of the software to handle such
new schemes still has to be written.

[And note that stat is an important system call - even with
new naming schemes we may need numbers - possibly some hash of
whatever ID we have found.]

Clearly, there will be a long transition period where these
schemes will coexist.

Now this old fashioned scheme has run into some limits -
it ran into them already several years ago, witness the
introduction of several scsi disk majors. Removing these limits
is not very difficult, so we do that now.

Your letters carry the tone of "it is forbidden to work on the
old scheme before you have shown how to solve all device naming
problems". But I am not going to.

You have opinions and questions about future schemes.
And so do I. But since time is limited I wrote you
already a handful of times: "Later".

This number stuff is simple and straightforward, we know precisely
what has to be done, but of course it needs to be done.

Naming on the other hand is intricate, lots of complications.
Device naming - but what is a device? Already that is complicated.
These are good discussions, and maybe sysfs will provide the answer
in certain cases, but these discussions are independent of dev_t.

Andries

             reply	other threads:[~2003-04-09 18:24 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-09 18:36 Andries.Brouwer [this message]
2003-04-09 21:11 ` Roman Zippel
  -- strict thread matches above, loose matches on Subject: below --
2003-04-09 18:40 James Bottomley
2003-04-09 20:54 ` Roman Zippel
2003-04-10  2:19   ` James Bottomley
2003-04-10 12:47     ` Roman Zippel
2003-04-10 15:30       ` James Bottomley
2003-04-10 23:53         ` Roman Zippel
2003-04-11  0:01           ` David Lang
2003-04-11  0:17             ` Roman Zippel
2003-04-11  0:47           ` Joel Becker
2003-04-11  1:11             ` Roman Zippel
2003-04-01 18:32 Andries.Brouwer
2003-03-31 23:41 Badari Pulavarty
2003-03-31 23:54 ` William Lee Irwin III
2003-03-31 23:55 ` Joel Becker
2003-04-02 12:18 ` Roman Zippel
2003-04-02 17:31   ` Badari Pulavarty
2003-04-02 22:03     ` H. Peter Anvin
2003-04-03 10:09       ` David Lang
2003-04-03 11:14         ` Lars Marowsky-Bree
2003-04-03 12:13     ` Roman Zippel
2003-04-03 13:37       ` Andries Brouwer
2003-04-03 14:01         ` Roman Zippel
2003-04-07 15:02           ` H. Peter Anvin
2003-04-07 20:10             ` Roman Zippel
2003-04-07 21:57               ` Roman Zippel
2003-04-07 22:43                 ` Kevin P. Fleming
2003-04-08 15:22                   ` Roman Zippel
2003-04-08 22:53                 ` Werner Almesberger
2003-04-08 23:11                   ` David Lang
2003-04-08 23:47                     ` Werner Almesberger
2003-04-08 23:58                       ` Kevin P. Fleming
2003-04-08 23:56                     ` H. Peter Anvin
2003-04-08 23:06                       ` Andrew Morton
2003-04-09  0:40                       ` Roman Zippel
2003-04-09  1:02                         ` Joel Becker
2003-04-09  1:25                           ` Roman Zippel
2003-04-09 16:42                       ` Roman Zippel
2003-04-09  0:21                   ` Roman Zippel
2003-04-11  9:58               ` Pavel Machek
2003-04-08 15:29             ` Roman Zippel
2003-03-28 15:33 Andries.Brouwer
2003-03-28 15:49 ` Roman Zippel
2003-03-28 11:46 Andries.Brouwer
2003-03-28 11:57 ` Roman Zippel
2003-03-28 11:10 Andries.Brouwer
2003-03-28 11:36 ` Roman Zippel
2003-03-30 20:05   ` H. Peter Anvin
2003-03-30 20:13     ` Roman Zippel
2003-03-27 22:37 Andries.Brouwer
2003-03-27 22:55 ` Roman Zippel
2003-03-27 20:27 Andries.Brouwer
2003-03-27 22:12 ` Roman Zippel
2003-03-27 22:55   ` Alan Cox
2003-03-27 23:19     ` Roman Zippel
2003-03-27 23:48       ` Greg KH
2003-03-28  9:47         ` Roman Zippel
2003-03-28 18:05           ` Joel Becker
2003-03-28 18:48             ` Roman Zippel
2003-03-31  8:31               ` bert hubert
2003-03-31  8:52                 ` Roman Zippel
2003-03-31 17:24                   ` Joel Becker
2003-03-31 21:32                     ` Roman Zippel
2003-03-31 22:18                       ` Alan Cox
2003-03-31 23:42                         ` Roman Zippel
2003-04-01 14:42                           ` Alan Cox
2003-04-01 16:35                             ` Greg KH
2003-04-02 13:02                               ` Roman Zippel
2003-04-01 14:42                           ` Alan Cox
2003-04-01 16:52                             ` Christoph Hellwig
2003-04-01 21:59                             ` H. Peter Anvin
2003-04-02  7:12                               ` Christoph Hellwig
2003-04-02  7:22                                 ` H. Peter Anvin
2003-03-31 23:45                         ` Joel Becker
2003-03-31 23:07                       ` Joel Becker
2003-03-31 23:35                         ` Roman Zippel
2003-03-27  1:09 Andries.Brouwer
2003-03-27 19:23 ` Roman Zippel
2003-03-30 20:10 ` H. Peter Anvin

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=UTC200304091836.h39IaWE29913.aeb@smtp.cwi.nl \
    --to=andries.brouwer@cwi.nl \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zippel@linux-m68k.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

all inboxes | Powered by JetHome®