public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andries.Brouwer@cwi.nl, linux-kernel@vger.kernel.org,
	torvalds@transmeta.com
Subject: Re: [PATCH] 2.5.18 IDE 73
Date: Thu, 30 May 2002 15:54:50 +0200	[thread overview]
Message-ID: <3CF62F2A.6030009@evision-ventures.com> (raw)
In-Reply-To: <UTC200205300019.g4U0JtH24034.aeb@smtp.cwi.nl> 	<3CF622F0.4050304@evision-ventures.com> <1022772774.12888.380.camel@irongate.swansea.linux.org.uk>

Alan Cox wrote:
> On Thu, 2002-05-30 at 14:02, Martin Dalecki wrote:
> 
>>1. util-linux doesn't cover half of the system utilities needed on
>>    a sanely actual Linux system.
>>2. The Linux vendors have to apply insane number of patches to it
>>    util it's moderately usable.
> 
> 
> So now you have nothing better to do than insult someone whose code
> works, is shipped in just about every distribution. Someone whose kernel
> patches are almost without fail perfect first time.
> 
> You should learn from Andries not mock him.

rpm -i util-linux-xxx.src.rpm

and count the patches yourself. Andries could be the Pope I would
still feel free to tell him what I think about this.
Ahh and just a remainder - poking at ports in kbdrate is bad and not
quite something I would learn from.

>>And after all it's rather trivial to iterate *all* disks present at boot
>>by hand and just going through /dev/sdaxxx chains. SCSI allocates
>>them consecutively anyway and there are typically not many ATA diskst around
>>there.
> 
> 
> You still need a way to talk all the disk devices. It might be that is
> devfs /dev/disk, but in case it hasn't permeated your skull yet, in such
> a situation then -devfs- would need such a list. We also have another

I don't use and don't care about devfs - it's a misconception in my opinnion.
What you are potining at is just another symptom of this simple fact.
After several years of beeing "official" it didn't develer up on
promises. There are some reasons why the Linux vendors out there get
well along without it. It is simple not necessary and even worser
introduces more problems that it promised to solve. No matter how
vigorous the propnents of it where before Linus give in. It's just another
try to work around the too narrow major/minor number spaces of Linux
and well see below:

> flaw here - we don't export the bit position of the partition/device
> split on each device which puts lots of horrible code into user space
> thats always going out of date
> 
> Oh and for /dev/disk/... to do labels and partitions it needs the
> partition data in the list too, remarkably like we have it now actually.

All what you are talking about here are afterthoughts to the a basic simple
flaw in the linux way af looking at devices:

Major numbers are sliced up to account for the fact that some drivers
abused slices of the major number space instead of minor numbers to
discriminate between different instances of the driver. Even worser
some drivers (most prominently ide-cd) hooked up completely
different devices on the same mojor number.
And last but not least: some devices which should be viewd as "same type"
are hooked up to different major numbers instead of sharing them.
Most prominent here are the differences between SCSI disks and ATA disks
for example. From a technical point of view they don't make *any* sense.


  reply	other threads:[~2002-05-30 14:53 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-30  0:19 [PATCH] 2.5.18 IDE 73 Andries.Brouwer
2002-05-30 13:02 ` Martin Dalecki
2002-05-30 15:32   ` Alan Cox
2002-05-30 13:54     ` Martin Dalecki [this message]
2002-05-30 15:05       ` Tomas Szepe
2002-05-30 15:13       ` Rene Rebe
2002-05-30 15:39       ` Wichert Akkerman
2002-05-30 16:13       ` Alan Cox
2002-05-30 14:20         ` Martin Dalecki
2002-05-30 15:31           ` Linus Torvalds
2002-05-30 18:55             ` Martin Dalecki
2002-05-30 15:25         ` Linus Torvalds
  -- strict thread matches above, loose matches on Subject: below --
2002-05-30 15:56 Andries.Brouwer
2002-05-30 14:43 Andries.Brouwer
2002-05-30 14:01 ` Martin Dalecki
2002-05-30 15:09   ` Rene Rebe
2002-05-31 13:25     ` Denis Vlasenko
2002-05-30 12:35 Bartlomiej Zolnierkiewicz
2002-05-29 23:40 Andries.Brouwer
2002-05-29 22:53 ` Martin Dalecki
2002-05-29 18:16 Andries.Brouwer
2002-05-29 18:07 Andries.Brouwer
2002-05-29 21:57 ` Martin Dalecki
2002-05-29 13:59 Gerald Champagne
2002-05-29 13:03 ` Martin Dalecki
2002-05-29 14:26   ` Gerald Champagne
2002-05-29 14:35   ` Russell King
2002-05-29 13:40     ` Martin Dalecki
2002-05-29 16:33   ` Vojtech Pavlik
2002-05-29 15:46     ` Martin Dalecki
2002-05-29 18:47       ` Alan Cox
2002-05-30  8:48         ` David Woodhouse
2002-05-30 12:22           ` Martin Dalecki
2002-05-29 17:55     ` Alan Cox
2002-05-29 17:01       ` Vojtech Pavlik
2002-05-29 16:05         ` Martin Dalecki
2002-05-29 17:05           ` Vojtech Pavlik
2002-05-29 18:43         ` Alan Cox
2002-05-25  2:02 Linux-2.5.18 Linus Torvalds
2002-05-29 12:11 ` [PATCH] 2.5.18 IDE 73 Martin Dalecki
2002-05-29 12:58   ` Zwane Mwaikambo
2002-05-29 12:52     ` 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=3CF62F2A.6030009@evision-ventures.com \
    --to=dalecki@evision-ventures.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox