public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andre Hedrick <andre@linux-ide.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"H. Peter Anvin" <hpa@transmeta.com>,
	Andries.Brouwer@cwi.nl, linux-kernel@vger.kernel.org,
	tytso@MIT.EDU
Subject: Re: Larger dev_t
Date: Wed, 28 Mar 2001 23:23:35 +0200	[thread overview]
Message-ID: <3AC25657.6CC01DFB@evision-ventures.com> (raw)
In-Reply-To: Pine.LNX.4.31.0103271545500.25282-100000@penguin.transmeta.com

Linus Torvalds wrote:
> 
> On Tue, 27 Mar 2001, Andre Hedrick wrote:
> >
> > Am I hearing you state you want dynamic device points and dynamic majors?
> 
> Yes and no.
> 
> We need static structures for user space - from a user perspective it
> makes a ton more sense to say "I want to see all disks" than it does to
> know that you have to do /dev/hd*, /dev/sd* plus all the extra magic
> combinations that can happen (USB etc).
> 
> So in a sense what I'm arguing for is for _stricter_ device numbers to the
> outside world.
> 
> But internally, it would be reasonably easy to make a mapping from those
> user-visible numbers to a much looser version.
> 
> One example of this is going to happen very early in 2.5.x: the whole
> "partitioning" stuff is going to go away from the driver, and into the
> ll_rw_block layer as just another disk re-mapping thing. We already do
> those kinds of re-mappings for LVM reasons anyway, and partitioning is not
> something a disk driver should know about, really.
> 
> And that kind of partitioning mapping automatically means that we'd need
> to remap minor numbers, and do it on a per-major basis (because the
> partitioning mapping right now is not actually the same between SCSI and
> IDE: IDE uses six bits of partitioning, while SCSI uses just four bits).
> And once you do that, you might as well start "remapping" major numbers
> too.
> 
> So let's say that you have two separate SCSI controllers - they would both
> show up on major #8, and different minor numbers. Right now, for example,
> controller 1 might have one disk, with minors 0-15 (for the whole disk and
> 15 partitions), and controller 2 might have two disks using minors 16-47.
> 
> As it stands now, the SCSI layer needs to do the remapping, and because
> the SCSI layer does the remapping, nothing but SCSI layer devices can use
> major #8.
> 
> But once you start doing partition mapping in ll_rw_block.c, you might as
> well get rid of the notion that "SCSI is major 8". You could easily have
> many different drivers, with many different queues, and remap them all to
> have major 8 (and different minors) so that it looks simple for a user
> that just wants to see SCSI disks.
> 
> Which is not to say that the same disk might not show up somewhere else
> too, if anybody wants it to. The _driver_ should just know "unit x on
> queue y", and then the driver might do whatever it wants (it might be, for
> example, that the driver actually wants to show multiple controllers as
> one queue, if the driver really wants to for some reason). And it should
> be possible to have two drivers that really have no idea at ALL about each
> other to just share the same major numbers.

Then please please please demangle other cases as well!
IDE is the one which is badging my head most. SCSI as well...

Granted I wouldn't mind a rebot with new /dev/* once!

  reply	other threads:[~2001-03-28 21:38 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
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 [this message]
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=3AC25657.6CC01DFB@evision-ventures.com \
    --to=dalecki@evision-ventures.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andre@linux-ide.org \
    --cc=hpa@transmeta.com \
    --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