All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <Joel.Becker@oracle.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andries.Brouwer@cwi.nl, akpm@digeo.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kdevt-diff
Date: Mon, 14 Apr 2003 12:15:15 -0700	[thread overview]
Message-ID: <20030414191512.GA4917@ca-server1.us.oracle.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0304141056450.19302-100000@home.transmeta.com>

On Mon, Apr 14, 2003 at 11:00:27AM -0700, Linus Torvalds wrote:
> Well, the thing is, we absolutely _do_ need to have the 8+8 split, in
> order to make old devices look the same old way for old binaries.

	Yes, and I support this 100%.

> The 16+16 split is not strictly necessary, but Andries pointed out to me
> that there are filesystems etc external storage that only support a 32-bit
> opaque dev_t, so we'd need to marshall the device number _some_ way for
> them anyway, and having a standard way to do that is better than having
> everybody come up with their own variations.

	Sure, but it's a marshall, not a reality.  One of the reasons
for choosing 64bits is that we can have large spaces for large things.
If a driver happens to get a number in the 16:16 space (or the 12:20
space, which I prefer as well), then it could run out of space and end
up with the multiple major problem.
	True, a truly dynamic scheme could make all of this irrelevant,
but I was just postulating that complexity isn't strictly necessary.
	I guess it is a trade off.  Do all devices greater than 8:8
become 32:32 and merely are masked to 16:16 on limited filesystems, or
do all devices smaller than 16:16/12:20 appear the same on all
filesystems, limited or not?

JOel

-- 

"You can get more with a kind word and a gun than you can with
 a kind word alone."
         - Al Capone

Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

  reply	other threads:[~2003-04-14 19:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-13 22:45 [PATCH] kdevt-diff Andries.Brouwer
2003-04-14 17:51 ` Joel Becker
2003-04-14 18:00   ` Linus Torvalds
2003-04-14 19:15     ` Joel Becker [this message]
2003-04-14 19:34     ` Roman Zippel
2003-04-16 16:43     ` H. Peter Anvin
2003-04-14 18:12 ` Roman Zippel
2003-04-14 18:18   ` Linus Torvalds
2003-04-14 18:31     ` Roman Zippel
2003-04-14 18:40       ` Linus Torvalds
2003-04-14 19:28         ` Roman Zippel
2003-04-14 19:51           ` Linus Torvalds
2003-04-14 20:02             ` Roman Zippel
2003-04-15 13:37     ` Roman Zippel
2003-04-23 15:19       ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2003-04-14 22:01 Andries.Brouwer
2003-04-14 22:11 ` Joel Becker
2003-04-14 22:18   ` Valdis.Kletnieks
2003-04-14 22:28     ` Joel Becker
2003-04-16 16:48     ` H. Peter Anvin
2003-04-16 20:19       ` Andries Brouwer
2003-04-16 20:27         ` H. Peter Anvin
2003-04-15 14:04 Andries.Brouwer
2003-04-15 14:53 ` Roman Zippel

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=20030414191512.GA4917@ca-server1.us.oracle.com \
    --to=joel.becker@oracle.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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.