Re: LANANA: Getting out of hand?

Re: LANANA: Getting out of hand?

[Rick Hohensee]

Torvalds sez
>On Mon, 14 May 2001, Alan Cox wrote:
>>
>> Except that Linus wont hand out major numbers, which means I can't even boot
>> simply off such a device. I bet the vendors in question dont think the sun
>> shines out of linus backside any more.
>
>Actually, it does. It's just that some people have gotten so blinded by my
>a** that they can no longer see it any more ;)
>
>The problem I have is that there are lots of _good_ solutions, but they
>all imply a bit more work than the bad ones.
>
>What does that result in? Everybody continues to use the simple old setup,
>which required no thought at all, but that is a pain to maintain.
>
>For example, the only thing you need in order to boot is to have a nice
>clean "disk" major number. That's it. Nothing fancy, nothing more.

To what extent do the code of the various drivers reflect that? i.e. is there
some code that is common to all block devices, and that is used by code that 
is common to all disk devices, that further is used by all drivers pretending 
to be IDE devices, which is further used by all code pretending to be EIDE 
devices, etc. ?  If you look at majors, say, as a binary tree which you 
walk in accordance with the bits in the major, can drivers nest like that?

I've wondered about that for a long time for various reasons.

Rick Hohensee
www.clienux.com

Re: LANANA: To Pending Device Number Registrants

[Alan Cox]

> Would you mind demonstrating such wonder? Old devices are still there,
> AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
> the ability to create device nodes for them.

Except that Linus wont hand out major numbers, which means I can't even boot
simply off such a device. I bet the vendors in question dont think the sun
shines out of linus backside any more.

Re: LANANA: Getting out of hand?

[God]

On Mon, 14 May 2001, Alan Cox wrote:

> Subject: Re: LANANA: To Pending Device Number Registrants
> 
> > Would you mind demonstrating such wonder? Old devices are still there,
> > AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
> > the ability to create device nodes for them.
> 
> Except that Linus wont hand out major numbers, which means I can't even boot
> simply off such a device. I bet the vendors in question dont think the sun
> shines out of linus backside any more.
> 


ouch ....  can't we all just get along? :<

Re: LANANA: Getting out of hand?

[Linus Torvalds]

On Mon, 14 May 2001, Alan Cox wrote:
> 
> Except that Linus wont hand out major numbers, which means I can't even boot
> simply off such a device. I bet the vendors in question dont think the sun
> shines out of linus backside any more.

Actually, it does. It's just that some people have gotten so blinded by my
a** that they can no longer see it any more ;)

The problem I have is that there are lots of _good_ solutions, but they
all imply a bit more work than the bad ones. 

What does that result in? Everybody continues to use the simple old setup,
which required no thought at all, but that is a pain to maintain.

For example, the only thing you need in order to boot is to have a nice
clean "disk" major number. That's it. Nothing fancy, nothing more. 

Look at what we have now:

 - ramdisk: major 1. Fair enough - ramdisk is special, in that it doesn't
   have any "real hardware". No problem.
 - SCSI disks:
	major 8, 65-71,
 - Compaq smart2:
	major 72-79
 - Compaq CISS:
	major 104-111
 - DASD;
	major 94
 - IDE:
	major 3, 22, 33-34, 56-57, 88-91

and then the small random ones.

NONE of these major numbers have _any_ redeeming qualities except for the
ramdisk. They should all be _one_ major number, namely "disk". There are
absolutely NO advantages to having separate devices for soem strange
compaq controllers and IDE disks. There is _no_ point in having some SCSI
disks show up at major 8, while others (who just happen to be attached to
a scsi bus that is not driven by the generic SCSI layer) show up at major
104 or whatever.

And it will never ever get fixed, unless somebody says "No more!". Which
I'm trying my best to say, except some people are so comfortable rolling
around in the shit that they have re-defined shit to be the new standard.

When Microsoft defines darkness to be standard, we laugh at them. When we
do it, Alan Cox stands up for it and claims that it's the best thing since
sliced bread. Double standards, anybody?

What I'm saying is: "No more SHIT!". I'm more than happy to give out a new
standard number for _disks_. I'm NOT AT ALL willing to say "Ok, Peter, go
ahead and give the next braindamaged Compaq/RedHat/Xxxx engineer another
random number so that we can dig ourselves deeper and deeper into this
shithole that Alan and others like so much".

How hard is it to generate a new "disk driver framework", and let people
register themselves, kind of like the "misc" drivers do. Except we'd only
allow DISKS. You could add something like

	register_disk_driver("compaq-ciss", nr_disks, &my_queue);

and then the disk driver framework will select a range of minor numbers
for the disks, and forward all requests that come to those minor numbers
to "my_queue". No major numbers. No fixed minors. And the user sees _one_
disk major, and doesn't care _what_ the hell is behind it.

But no. When I tell people "enough is enough", people want to continue
with the unbearably stupid and ugly thing we've always had, without
realizing that the _real_ problem is not that we have too few major
numbers, but the real problem is that people have mis-used the ones we
_do_ have, and the fact that we have too few _minor_ numbers (which is
easily fixable, and where 20 bits is plenty).

		Linus

Re: LANANA: Getting out of hand?

[Linus Torvalds]

On Mon, 14 May 2001, Linus Torvalds wrote:
> 
> How hard is it to generate a new "disk driver framework", and let people
> register themselves, kind of like the "misc" drivers do. Except we'd only
> allow DISKS. You could add something like
> 
> 	register_disk_driver("compaq-ciss", nr_disks, &my_queue);

Note: one _important_ part of this is that absolutely _nobody_ registers a
disk driver except for a controller that is physically found on the
machine. 

None of this stupid "we have numbers pre-allocated for hardware that does
not even exists on this machine" crap that the current setup is full of. 

This way, you can pretty much depend on the fact that in any "normal"
configuration, you'll find disks at "disk0", "disk1", ... completely
regardless of whether the machine has a IDE controller, a "old-fashioned
SCSI" controller, or a Compaq smart-raid controller. And THAT is useful.  
You can migrate filesystem setups from one machine to another, without
worrying about the fact that one machine has IDE disks and another has
SCSI disks - the filesystem will just work, and the kernels will just
boot.

THAT is how it is supposed to work.

For people who care about where the disks are (0.01% of all people, and
half of those are misguded anyway), you can have a /proc interface or an
ioctl or something. 

But don't make excuses for the current setup. And understand why we must
NOT continue to just give out major numbers indiscriminately.

[ Oh, and _please_ don't Cc: me on this discussion. I'm not that
  interested. I know what I want, and I've let the current mess go on for
  too long. If it takes some pain to fix it, then so be it. It needs to be
  fixed, even if people suddenly start thinking that the light of my a**
  dimmed a bit. That's ok. I just don't want to really fill my inbox - I
  read the kernel mailing list with a newsreader and the "D" key. ]

		Linus

Re: LANANA: Getting out of hand?

[Geert Uytterhoeven]

On Mon, 14 May 2001, Linus Torvalds wrote:
> On Mon, 14 May 2001, Alan Cox wrote:
> > Except that Linus wont hand out major numbers, which means I can't even boot
> > simply off such a device. I bet the vendors in question dont think the sun
> > shines out of linus backside any more.
> 
> For example, the only thing you need in order to boot is to have a nice
> clean "disk" major number. That's it. Nothing fancy, nothing more. 
> 
> Look at what we have now:
> 
>  - ramdisk: major 1. Fair enough - ramdisk is special, in that it doesn't
>    have any "real hardware". No problem.
>  - SCSI disks:
> 	major 8, 65-71,
>  - Compaq smart2:
> 	major 72-79
>  - Compaq CISS:
> 	major 104-111
>  - DASD;
> 	major 94
>  - IDE:
> 	major 3, 22, 33-34, 56-57, 88-91
> 
> and then the small random ones.
> 
> NONE of these major numbers have _any_ redeeming qualities except for the
> ramdisk. They should all be _one_ major number, namely "disk". There are
> absolutely NO advantages to having separate devices for soem strange
> compaq controllers and IDE disks. There is _no_ point in having some SCSI
> disks show up at major 8, while others (who just happen to be attached to
> a scsi bus that is not driven by the generic SCSI layer) show up at major
> 104 or whatever.

    [...]

> How hard is it to generate a new "disk driver framework", and let people
> register themselves, kind of like the "misc" drivers do. Except we'd only
> allow DISKS. You could add something like
> 
> 	register_disk_driver("compaq-ciss", nr_disks, &my_queue);
> 
> and then the disk driver framework will select a range of minor numbers
> for the disks, and forward all requests that come to those minor numbers
> to "my_queue". No major numbers. No fixed minors. And the user sees _one_
> disk major, and doesn't care _what_ the hell is behind it.

Looks exactly like what we used to do for serial ports on the m68k platform...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: LANANA: Getting out of hand?

[Alan Cox]

> How hard is it to generate a new "disk driver framework", and let people
> register themselves, kind of like the "misc" drivers do. Except we'd only
> allow DISKS. You could add something like
> 
> 	register_disk_driver("compaq-ciss", nr_disks, &my_queue);

Why bother. Devfs does that already. Thats the enumeration problem 

> and then the disk driver framework will select a range of minor numbers
> for the disks, and forward all requests that come to those minor numbers
> to "my_queue". No major numbers. No fixed minors. And the user sees _one_
> disk major, and doesn't care _what_ the hell is behind it.

The user running devfs sees /dev/disc or /devices/disc and doesnt care
whats behind it already. They also see what is scsi and the like providing
they care to ask. The latter is essential to make ioctl work.

Doing a grep across about a large amount of source code I found several very
definite uses the device type:

1	Is file A the same as file B	

	This continues to work fine

2	Is file A on mountpoint B

	This continues to work fine

3	Are you running this on a sane device

	Joystick, hdparm, ...

4	Which ioctl set can I use of device A

	This breaks. Examples of this include tools like mt-st which has to
	use different ioctls according to the tape class. Our ioctls overlap
	so it isnt safe to issue them and pray

5	Deep nasty lowlevel grungy knowledge

	Things like lilo that knows and to an extent has to know more about
	the universe than is nice.

3 and 4 are variants of the same thing really. The lack of any way other than
the major number to say 'What ioctl classes does this device support'. IMHO
thats a thing you have to fix first - a way to query the device and get back
{"disk", "scsi-disk", "scsi-lowlevel"} or {"disk", "cpqarray"}

The underlying name/number thing is a red herring. You don't need that to
do /dev/disc nicely. devfs rather proved it. 

Alan

Re: LANANA: Getting out of hand?

[Martin Dalecki]

Linus Torvalds wrote:
> 
> On Mon, 14 May 2001, Alan Cox wrote:
> >
> > Except that Linus wont hand out major numbers, which means I can't even boot
> > simply off such a device. I bet the vendors in question dont think the sun
> > shines out of linus backside any more.
> 
> Actually, it does. It's just that some people have gotten so blinded by my
> a** that they can no longer see it any more ;)
> 
> The problem I have is that there are lots of _good_ solutions, but they
> all imply a bit more work than the bad ones.
> 
> What does that result in? Everybody continues to use the simple old setup,
> which required no thought at all, but that is a pain to maintain.
> 
> For example, the only thing you need in order to boot is to have a nice
> clean "disk" major number. That's it. Nothing fancy, nothing more.
> 
> Look at what we have now:
> 
>  - ramdisk: major 1. Fair enough - ramdisk is special, in that it doesn't
>    have any "real hardware". No problem.
>  - SCSI disks:
>         major 8, 65-71,
>  - Compaq smart2:
>         major 72-79
>  - Compaq CISS:
>         major 104-111
>  - DASD;
>         major 94
>  - IDE:
>         major 3, 22, 33-34, 56-57, 88-91
> 
> and then the small random ones.
> 
> NONE of these major numbers have _any_ redeeming qualities except for the
> ramdisk. They should all be _one_ major number, namely "disk". There are
> absolutely NO advantages to having separate devices for soem strange
> compaq controllers and IDE disks. There is _no_ point in having some SCSI
> disks show up at major 8, while others (who just happen to be attached to
> a scsi bus that is not driven by the generic SCSI layer) show up at major
> 104 or whatever.

And then the IDE stuff is stiuoid to use the same major numbers for
in fact entierly different devices like CD-ROM and IDE disk drivers on
the same major... This makes it VERY uncomfortable to guarantee that
for example the sector size and driver read ahead are properties
tighted to the major number alone... In fact Linux is bundling 
read ahead with the major number only, in esp. inside the RAID drivers
which is entierly wrong! (see blksize_size array and read_ahead array).

And yes the RAID drivers are in particular *VERY* stiupid in
terms of major/minor number usage.