From: "H. Peter Anvin" <hpa@transmeta.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andries.Brouwer@cwi.nl, alan@lxorguk.ukuu.org.uk,
linux-kernel@vger.kernel.org, tytso@MIT.EDU
Subject: Re: Larger dev_t
Date: Tue, 27 Mar 2001 11:28:45 -0800 [thread overview]
Message-ID: <3AC0E9ED.3324F697@transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.31.0103271028280.24734-100000@penguin.transmeta.com>
This is my opinion on the issue. Short summary: "I'm sick of the
administrative burden associated with keeping dev_t dense."
Linus Torvalds wrote:
>
> And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every
> device needs a unique number. Do you ever envision seeing that "ls -l"
> taking about 500 billion years to complete? I don't. I don't think you do.
> But that's how ludicrous a 64-bit device number is.
>
That's how ludicrous a *dense* 64-bit device number is. I have to say I
disagree with you that sparse number spaces are a bad idea. The
IPv4->IPv6 transition people have looked at the issues of number spaces
and how much harder they get to keep dense when the size of the
numberspace grows, because your lookup operation becomes so much more
painful. Any time you have to take a larger number space and squeeze it
into a smaller number space, you get some serious pain.
Part of the reason we haven't -- quite -- run out of 8-bit majors yet is
because I have been an absolute *bastard* with registrants lately. It
would cut down on my workload if I could assign majors without worrying
too much about whether or not that particular driver is really going to
be made public.
64 bits is obviously excessive, but I really don't feel comfortable
saying that only 12 bits of major is sufficient. 16 I would buy, but I
don't think 16 bits of minor is sufficient. Given that, it seems to me
-- especially since dev_t isn't exactly the most accessed data type in
the universe -- that the conceptual simplicity of keeping the major and
minor separate in individual 32-bit words really is just as well. YES,
it's overengineering, but the cost is very small; the cost of
underengineering is having to go through yet another painful transition.
Unfortunately, the Linux community seems to have some serious problems
with getting system-wide transitions to happen, especially the ones that
involve ABI changes. This needs to be taken into account.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
next prev parent reply other threads:[~2001-03-27 19:31 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-27 9:29 Larger dev_t Andries.Brouwer
2001-03-27 18:48 ` Linus Torvalds
2001-03-27 19:28 ` H. Peter Anvin [this message]
2001-03-27 19:51 ` Linus Torvalds
2001-03-27 21:21 ` Alan Cox
2001-03-27 21:35 ` Linus Torvalds
2001-03-27 22:02 ` Andre Hedrick
2001-03-27 23:57 ` Linus Torvalds
2001-03-28 21:23 ` Martin Dalecki
2001-03-28 21:40 ` H. Peter Anvin
2001-03-28 21:44 ` Andre Hedrick
2001-03-27 22:16 ` Alan Cox
2001-03-27 22:16 ` H. Peter Anvin
2001-03-27 22:43 ` Russell King
2001-03-28 16:59 ` Jeff Randall
2001-03-28 0:07 ` Linus Torvalds
2001-03-28 0:10 ` H. Peter Anvin
2001-03-28 0:24 ` Linus Torvalds
2001-03-28 2:19 ` Alan Cox
2001-03-28 7:08 ` Andre Hedrick
2001-03-28 21:32 ` Martin Dalecki
2001-03-29 3:53 ` Alan Cox
2001-03-29 11:02 ` Martin Dalecki
2001-04-02 20:02 ` Alan Cox
2001-04-03 7:25 ` Martin Dalecki
2001-04-03 12:19 ` Alan Cox
2001-04-03 12:13 ` Martin Dalecki
2001-04-03 12:38 ` Alan Cox
2001-04-04 8:08 ` Rogier Wolff
2001-03-30 6:54 ` Kai Henningsen
2001-03-28 21:18 ` Martin Dalecki
2001-03-27 22:13 ` H. Peter Anvin
2001-03-27 22:55 ` Dan Hollis
2001-03-27 22:58 ` H. Peter Anvin
2001-03-27 23:42 ` Richard Gooch
2001-03-28 1:03 ` Paul Jakma
2001-03-28 1:35 ` Alexander Viro
2001-03-27 23:44 ` Andrew Pimlott
2001-03-28 0:28 ` Albert D. Cahalan
2001-03-28 3:58 ` Johan Kullstam
2001-03-28 4:23 ` Alexander Viro
2001-03-28 11:57 ` Jesse Pollard
2001-03-28 18:13 ` Oliver Neukum
2001-03-28 19:05 ` Jesse Pollard
2001-03-28 19:50 ` Oliver Neukum
2001-03-28 21:36 ` Martin Dalecki
2001-03-28 21:09 ` Martin Dalecki
2001-03-28 21:24 ` H. Peter Anvin
2001-03-28 21:46 ` Alexander Viro
2001-03-28 20:54 ` Martin Dalecki
2001-03-28 11:52 ` Pjotr Kourzanoff
2001-03-28 12:11 ` Tim Jansen
2001-03-27 19:27 ` Albert D. Cahalan
-- strict thread matches above, loose matches on Subject: below --
2001-04-03 14:48 Wayne.Brown
2001-04-03 15:34 ` Bart Trojanowski
2001-04-02 21:59 Andries.Brouwer
2001-04-02 20:17 Andries.Brouwer
2001-04-02 21:45 ` Alan Cox
2001-04-03 7:28 ` Martin Dalecki
2001-04-03 10:09 ` Ingo Oeser
2001-04-03 12:06 ` Alan Cox
2001-04-03 12:20 ` Ingo Oeser
2001-04-03 12:15 ` Martin Dalecki
2001-04-03 12:53 ` Alan Cox
2001-04-03 16:05 ` Richard Gooch
2001-04-03 16:34 ` Alexander Viro
2001-04-03 16:58 ` Richard Gooch
2001-04-03 16:54 ` Alan Cox
2001-04-03 17:02 ` Richard Gooch
2001-04-03 12:41 ` Alan Cox
2001-04-03 23:28 ` Tim Wright
2001-03-27 22:38 Jesse Pollard
2001-03-27 22:44 ` H. Peter Anvin
2001-03-26 21:18 John Byrne
2001-03-26 22:12 ` Linus Torvalds
2001-03-26 23:41 ` Guest section DW
2001-03-25 12:31 Andries.Brouwer
2001-03-25 15:35 ` Wichert Akkerman
2001-03-25 16:15 ` Mitchell Blank Jr
2001-03-25 16:54 ` Michel Wilson
2001-03-25 17:12 ` Jeff Garzik
2001-03-25 17:00 ` Jamie Lokier
2001-03-25 17:07 ` Anton Altaparmakov
2001-03-25 17:37 ` Michel Wilson
2001-03-25 18:21 ` Guest section DW
2001-03-25 20:50 ` diego
2001-03-25 17:55 ` Gerry
2001-03-27 6:03 ` Linus Torvalds
2001-03-24 16:13 Andries.Brouwer
2001-03-24 14:25 Andries.Brouwer
2001-03-24 14:40 ` Jeff Garzik
2001-03-24 15:00 ` Alexander Viro
2001-03-25 14:22 ` Martin Dalecki
2001-03-25 3:24 ` Linus Torvalds
2001-03-25 14:35 ` Martin Dalecki
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=3AC0E9ED.3324F697@transmeta.com \
--to=hpa@transmeta.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=tytso@MIT.EDU \
/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