linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Andries.Brouwer@cwi.nl, Andrew Morton <akpm@digeo.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kdevt-diff
Date: Mon, 14 Apr 2003 11:40:12 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0304141133390.19302-100000@home.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0304142022370.5042-100000@serv>


On Mon, 14 Apr 2003, Roman Zippel wrote:
> > I think the single block-device major is a totally separate issue, and has 
> > nothing to do with allowing big device_t representations. I do not see why 
> > Andries patch would be anything else than infrastructure for future 
> > expansion.
> 
> Expansion into what?

That's the point - Andries patch is a pure extension of the number space 
into user space. 

If you think that clashes with anything else, than that "anything else" is 
_broken_. 

> The knowledge about dev_t is already reduced to a minimum in a lot of 
> block device drivers. register_blkdev() is already pretty much a dummy and 
> not a requirement anymore.

So why do you think Andries patch clashes?

Also, I don't think your patch is proper. The point about having a single
disk number space means that IDE and SCSI disks would show up there too -
users simply shouldn't need to care about the differences (which is not
just major numbers, but also the silly difference in how the partitioning
splits minor numbers).

But at the same time, for backwards compatibility clearly they have to
show up in the _old_ places too. Which really implies that there needs to
be a mapping function for the old numbers into the proper block device
queues etc, so that people can still use the old /dev nodes when they
upgrade their kernel.

		Linus




  reply	other threads:[~2003-04-14 18:31 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
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 [this message]
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
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=Pine.LNX.4.44.0304141133390.19302-100000@home.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=akpm@digeo.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;
as well as URLs for NNTP newsgroup(s).