[PATCH] 2.5.18 IDE 73

[PATCH] 2.5.18 IDE 73

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

Tue May 28 17:25:29 CEST 2002 ide-clean-73

- Merge ide-probe.c and ide-features.c in to one single file.  They are
   mutually doing basically the same and in esp. in case of the device ID
   retrieval there *is* quite a lot of code duplication between them.
   ide-geometry.c fits there as well.

- Remove ide_xfer_verbose - it wasn't really used.

- Don't allow check_partition to be more clever then the writer of a driver.
   It was interfering with drivers which check partitions as they go and
   finally if we want to spew something about it - we can do it ourself.

- Eliminate ide_geninit(). We scan for partitions now inside the recently
   introduced attach method. register_disk() is broken by the way and 90% of
   places where it's used it is doing literally nothing. Either some one didn't
   finish some code or the code is basically just junk from the past.

   Anyway we grok the partitions now one by one as we detect the channels.

- ide_driveid_update is gone. We don't report the drive id through /proc/ide
   and we don't have to update it any longer on the fly. Still someone out there
   complaining that it went away!?

- Use the global driver spin-lock to protect data structure access in the
   ide_register_subdriver() function instead of blatantly disabling all
   interrupts.

[-- Attachment #2: ide-clean-73.diff.gz --]
[-- Type: application/x-gzip, Size: 31347 bytes --]

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Zwane Mwaikambo wrote:
> Hi Marcin,
> 	Just a few comments, please don't mistake it for nitpicking, but 
> perhaps a request for clarification.

No problem at all.

> 
> On Wed, 29 May 2002, Martin Dalecki wrote:
> 
> 
>>- Don't allow check_partition to be more clever then the writer of a driver.
>>   It was interfering with drivers which check partitions as they go and
>>   finally if we want to spew something about it - we can do it ourself.
> 
> 
> Should this really be the case? Isn't the driver the one that is 
> interfering in this case?

No please have a close look at the boot sequence of
the 2.5.18 kernel without the above patch applied.
It will:

1. Spew the "Paritition checks" message ony once directly after the
    detection of the drive /dev/hda geometry and then never again.

2. It will check the partitions twice, without the above message.

After hot plugging some device the above message should be
perhaps reintroduced, but right now it won't appear at all.

The ideal thing we should do would be:

Detect a channel, detect a disk on a channel, detect partitions on it.

Right now we where doing:
Look for disks, where there are disks, assume there is a channel too.
Look for all disks goemetries.
Look for all disks partitions.

Wuite worng in the context of  aproper support for hot
plugging stuff.

So I'm *very* confident about the above change.

>>   Anyway we grok the partitions now one by one as we detect the channels.
> 
> 
> Same as above.

What's your problem here - that's the proper thing to do.

Re: [PATCH] 2.5.18 IDE 73

[Zwane Mwaikambo]

Hi Marcin,
	Just a few comments, please don't mistake it for nitpicking, but 
perhaps a request for clarification.

On Wed, 29 May 2002, Martin Dalecki wrote:

> - Don't allow check_partition to be more clever then the writer of a driver.
>    It was interfering with drivers which check partitions as they go and
>    finally if we want to spew something about it - we can do it ourself.

Should this really be the case? Isn't the driver the one that is 
interfering in this case?

>    Anyway we grok the partitions now one by one as we detect the channels.

Same as above.

Thanks,
	Zwane Mwaikambo

-- 
http://function.linuxpower.ca
		

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Gerald Champagne wrote:
>>- ide_driveid_update is gone. We don't report the drive id through 
>>/proc/ide and we don't have to update it any longer on the fly. Still 
>>someone out there complaining that it went away!?
> 
> 
> But the id information is still available through the ioctl interface. 
> ide_driveid_update was used to update the dma_ultra, dma_mword, and
> dma_lword fields in the id structure after changing the rate with an
> ioctl command.  Won't these fields be wrong if the rate is changed after
> initialization?  Won't "hdparm -i" show outdated and incorrect
> information.
> 
> It's good to see the duplicate identify routine go away, but the ioctl
> shouldn't return incorrect information.  Can the remaining identify
> routine be modified and called directly from the ioctl that returns the
> id information?
> 
> Gerald

Dear Gerald please look closer. The hdparm -i is executing the
drive id command directly and does *not* rely on the internally
permanently dragged around id structure. So the change I did
is entierly fine. Just go ahead and check whatever hdparm -i /dev/hdx
reports the proper thing after changing some dma setting.
It does - I did check it :-).

BTW> The next thing to be gone is simple the fact that we drag
around the id information permanently, where infact only
some capabilitie fields are sucked out of it and the
device identification string is only needed for reporting
during boot-up.

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Russell King wrote:
> On Wed, May 29, 2002 at 03:03:27PM +0200, Martin Dalecki wrote:
> 
>>Dear Gerald please look closer. The hdparm -i is executing the
>>drive id command directly and does *not* rely on the internally
> 
> 
> hdparm -i uses the HDIO_GET_IDENTITY ioctl, which returns drive->id.
> It doesn't obtain the ID from the drive.  hdparm -I asks the
> identity from the drive.

Yes. But this will be just changed soon, since there
is no reaons at all to don't just read it always from the drive, in esp.
in face of the above.

BTW.> The above function was only used when the user
invoked ioctl() - that was my point.

> hdparm --help gives some hints:
> 
>  -i   display drive identification
>  -I   read drive identification directly from drive
> 
> and the man page is quite clear:
> 
>        -i     Display the identification info that  was  obtained
>               from the drive at boot time, if available.  This is
>               a feature of modern IDE drives, and may not be sup­
>               ported  by older devices.  The data returned may or
>               may not be current,  depending  on  activity  since
>               booting  the system.  However, the current multiple
>               sector mode count is  always  shown.   For  a  more
>               detailed interpretation of the identification info,
>               refer to AT Attachment Interface  for  Disk  Drives
>               (ANSI  ASC X3T9.2 working draft, revision 4a, April
>               19/93).
> 
>        -I     Request  identification  info  directly  from   the
>               drive,  which  is displayed in its raw form with no
>               endian changes or corrections.   Text  strings  may
>               appear mangled when using -I but that is NOT a bug.
>               Otherwise similar to the -i option.
> 



-- 
- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R

Re: [PATCH] 2.5.18 IDE 73

[Gerald Champagne]

>- ide_driveid_update is gone. We don't report the drive id through 
> /proc/ide and we don't have to update it any longer on the fly. Still 
> someone out there complaining that it went away!?

But the id information is still available through the ioctl interface. 
ide_driveid_update was used to update the dma_ultra, dma_mword, and
dma_lword fields in the id structure after changing the rate with an
ioctl command.  Won't these fields be wrong if the rate is changed after
initialization?  Won't "hdparm -i" show outdated and incorrect
information.

It's good to see the duplicate identify routine go away, but the ioctl
shouldn't return incorrect information.  Can the remaining identify
routine be modified and called directly from the ioctl that returns the
id information?

Gerald

Re: [PATCH] 2.5.18 IDE 73

[Gerald Champagne]

> 
> Dear Gerald please look closer. The hdparm -i is executing the
> drive id command directly and does *not* rely on the internally
> permanently dragged around id structure. So the change I did
> is entierly fine. Just go ahead and check whatever hdparm -i /dev/hdx
> reports the proper thing after changing some dma setting.
> It does - I did check it :-).

Ah, sorry about that.  I missed that in your patch.  The previous
version of the ioctl just returned copied the values from the id
structure.  Doing the id on the fly is much more accurate and will catch
any other fields that happen to change over time.  

> BTW> The next thing to be gone is simple the fact that we drag
> around the id information permanently, where infact only
> some capabilitie fields are sucked out of it and the
> device identification string is only needed for reporting
> during boot-up.

That sounds good.  That would make it easier to see what values from the
id are actually used.

Thanks.

Gerald

Re: [PATCH] 2.5.18 IDE 73

[Russell King]

On Wed, May 29, 2002 at 03:03:27PM +0200, Martin Dalecki wrote:
> Dear Gerald please look closer. The hdparm -i is executing the
> drive id command directly and does *not* rely on the internally

hdparm -i uses the HDIO_GET_IDENTITY ioctl, which returns drive->id.
It doesn't obtain the ID from the drive.  hdparm -I asks the
identity from the drive.

hdparm --help gives some hints:

 -i   display drive identification
 -I   read drive identification directly from drive

and the man page is quite clear:

       -i     Display the identification info that  was  obtained
              from the drive at boot time, if available.  This is
              a feature of modern IDE drives, and may not be sup­
              ported  by older devices.  The data returned may or
              may not be current,  depending  on  activity  since
              booting  the system.  However, the current multiple
              sector mode count is  always  shown.   For  a  more
              detailed interpretation of the identification info,
              refer to AT Attachment Interface  for  Disk  Drives
              (ANSI  ASC X3T9.2 working draft, revision 4a, April
              19/93).

       -I     Request  identification  info  directly  from   the
              drive,  which  is displayed in its raw form with no
              endian changes or corrections.   Text  strings  may
              appear mangled when using -I but that is NOT a bug.
              Otherwise similar to the -i option.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Vojtech Pavlik wrote:
> On Wed, May 29, 2002 at 03:03:27PM +0200, Martin Dalecki wrote:
> 
> 
>>BTW> The next thing to be gone is simple the fact that we drag
>>around the id information permanently, where infact only
>>some capabilitie fields are sucked out of it and the
>>device identification string is only needed for reporting
>>during boot-up.
> 
> 
> Also for black/whitelists. And we're going to need those, though maybe
> the current data in them is not worth much.


Indeed thanks for the reminder. However as far as I'm concerned
I would rather agree that the data currently present in those
black/whitelists is basically useless. Most of the disks
present there are simple plain just obsoleted by a great margin
or have already dyed due to the severe firmware errors they did contain.
And finally this data was basically collected during the fortunately
long bast days where cmd64x chips where prevalent on VLB 486 systems.
It's most propably not accurate for more modenr ATA host chip cells.

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Vojtech Pavlik wrote:
> On Wed, May 29, 2002 at 06:55:38PM +0100, Alan Cox wrote:
> 
> 
>>>Also for black/whitelists. And we're going to need those, though maybe
>>>the current data in them is not worth much.
>>
>>I'm hopeful they still are. The early drives with DMA problems won't
>>have changed over time, and I've been updating the others when I get
>>data from vendors. Promise for example recently sent me a couple to add
> 
> 
> The early drives haven't changed, but the drivers for the controllers
> which they were tested on changed (or will change soon). Namely the
> lists of PIO mode limits were wrong very often. This is mainly because
> some of the (now almost unused) drivers program the timings incorrectly
> into the controller registers.
> 
> I can't say much about the more recent entries, except for that it'd be
> nice to add a date when the entry was last tested and with what result
> to each of them over time.

And plese note as well that we don't need the whole id struct, but just
the name of the drive as well. Which is much less of a hassle anyway.

Re: [PATCH] 2.5.18 IDE 73

[Vojtech Pavlik]

On Wed, May 29, 2002 at 03:03:27PM +0200, Martin Dalecki wrote:

> BTW> The next thing to be gone is simple the fact that we drag
> around the id information permanently, where infact only
> some capabilitie fields are sucked out of it and the
> device identification string is only needed for reporting
> during boot-up.

Also for black/whitelists. And we're going to need those, though maybe
the current data in them is not worth much.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.18 IDE 73

[Vojtech Pavlik]

On Wed, May 29, 2002 at 06:55:38PM +0100, Alan Cox wrote:

> > Also for black/whitelists. And we're going to need those, though maybe
> > the current data in them is not worth much.
> 
> I'm hopeful they still are. The early drives with DMA problems won't
> have changed over time, and I've been updating the others when I get
> data from vendors. Promise for example recently sent me a couple to add

The early drives haven't changed, but the drivers for the controllers
which they were tested on changed (or will change soon). Namely the
lists of PIO mode limits were wrong very often. This is mainly because
some of the (now almost unused) drivers program the timings incorrectly
into the controller registers.

I can't say much about the more recent entries, except for that it'd be
nice to add a date when the entry was last tested and with what result
to each of them over time.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.18 IDE 73

[Vojtech Pavlik]

On Wed, May 29, 2002 at 06:05:38PM +0200, Martin Dalecki wrote:
> Vojtech Pavlik wrote:
> > On Wed, May 29, 2002 at 06:55:38PM +0100, Alan Cox wrote:
> > 
> > 
> >>>Also for black/whitelists. And we're going to need those, though maybe
> >>>the current data in them is not worth much.
> >>
> >>I'm hopeful they still are. The early drives with DMA problems won't
> >>have changed over time, and I've been updating the others when I get
> >>data from vendors. Promise for example recently sent me a couple to add
> > 
> > 
> > The early drives haven't changed, but the drivers for the controllers
> > which they were tested on changed (or will change soon). Namely the
> > lists of PIO mode limits were wrong very often. This is mainly because
> > some of the (now almost unused) drivers program the timings incorrectly
> > into the controller registers.
> > 
> > I can't say much about the more recent entries, except for that it'd be
> > nice to add a date when the entry was last tested and with what result
> > to each of them over time.
> 
> And plese note as well that we don't need the whole id struct, but just
> the name of the drive as well. Which is much less of a hassle anyway.

Correct. And the manufacturer and the revision.

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] 2.5.18 IDE 73

[Alan Cox]

On Wed, 2002-05-29 at 17:33, Vojtech Pavlik wrote:
> Also for black/whitelists. And we're going to need those, though maybe
> the current data in them is not worth much.

I'm hopeful they still are. The early drives with DMA problems won't
have changed over time, and I've been updating the others when I get
data from vendors. Promise for example recently sent me a couple to add

Re: [PATCH] 2.5.18 IDE 73

[Andries.Brouwer]

    - Don't allow check_partition to be more clever then the writer of a driver.
       It was interfering with drivers which check partitions as they go and
       finally if we want to spew something about it - we can do it ourself.

    - Eliminate ide_geninit(). We scan for partitions now inside the recently
       introduced attach method. register_disk() is broken by the way and 90% of
       places where it's used it is doing literally nothing. Either some one didn't
       finish some code or the code is basically just junk from the past.

       Anyway we grok the partitions now one by one as we detect the channels.

Pity you send this gzipped, otherwise I would have looked at the code.

Yes, 90% of the uses of register_disk() are empty. I submitted a patch
to remove this cruft last year, but Al was attached to it - wanted to
make them nonempty.

About scanning for partitions I say the same thing I said to Al a few
days ago:
Several partitioning schemes exist, and reading partition tables is not
something a driver should do without getting explicit requests.
For all we know the disk contents may be completely random.

You should offer the list of disks seen to user space, and user space
should decide which disks have to be investigated, and tell the kernel
about the partitions it wants to have on these disks.
That way all knowledge about partitioning, dynamic disks, disk managers
and the like is removed from the kernel, and moved into partx-type code.


Andries

Re: [PATCH] 2.5.18 IDE 73

[Andries.Brouwer]

> hdparm -i is executing the drive id command directly
> and does *not* rely on the internally permanently dragged around id structure.

The situation used to be that "hdparm -i" used the information read at boot time,
while "hdparm -I" read the current situation. That was sometimes useful.

Andries

Re: [PATCH] 2.5.18 IDE 73

[Alan Cox]

On Wed, 2002-05-29 at 18:01, Vojtech Pavlik wrote:
> The early drives haven't changed, but the drivers for the controllers
> which they were tested on changed (or will change soon). Namely the
> lists of PIO mode limits were wrong very often. This is mainly because
> some of the (now almost unused) drivers program the timings incorrectly
> into the controller registers.

Ok I'm not sure on the PIO ones. The DMA blacklist is a set of devices
that had actual firmware side problems on the whole and vendor confirmed
ones.
 
> I can't say much about the more recent entries, except for that it'd be
> nice to add a date when the entry was last tested and with what result
> to each of them over time.

The ones I have are from vendors whom I hope know what they are doing.
The one exception is an item which is missing which is the needed
blacklist of UDMA on the OSB4 for one vendor at least (MWDMA is fine)

Re: [PATCH] 2.5.18 IDE 73

[Alan Cox]

On Wed, 2002-05-29 at 16:46, Martin Dalecki wrote:
> Indeed thanks for the reminder. However as far as I'm concerned
> I would rather agree that the data currently present in those
> black/whitelists is basically useless. Most of the disks
> present there are simple plain just obsoleted by a great margin

Lots of people are still using them. Removing the blacklists "because
they are old disks" is not what I'd consider good practice.

> It's most propably not accurate for more modenr ATA host chip cells.

For the DMA blacklists thats not the case. You need to get more direct
contacts with the IDE/ATA drive vendors and documentation sets. The WDC
DMA blacklist entries for example are from specific WDC issued lists of
problem drives. 

Alan

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Andries.Brouwer@cwi.nl wrote:
>     - Don't allow check_partition to be more clever then the writer of a driver.
>        It was interfering with drivers which check partitions as they go and
>        finally if we want to spew something about it - we can do it ourself.
> 
>     - Eliminate ide_geninit(). We scan for partitions now inside the recently
>        introduced attach method. register_disk() is broken by the way and 90% of
>        places where it's used it is doing literally nothing. Either some one didn't
>        finish some code or the code is basically just junk from the past.
> 
>        Anyway we grok the partitions now one by one as we detect the channels.
> 
> Pity you send this gzipped, otherwise I would have looked at the code.

Well otherwise it wouldn't get through lkml. And since there
are actually right now quite a lot of people interressted in
the intermediate patches I'm sending it gzip-ed.
And no I don't buy in to the fact that we need a separate
mailing list for every single topic out there.
The traffic on lkml isn't that high if you learn to filter:

1. Some very active people who are posting only garbage.
2. Some perpetuant topics which are irrelevant.

> Yes, 90% of the uses of register_disk() are empty. I submitted a patch
> to remove this cruft last year, but Al was attached to it - wanted to
> make them nonempty.

For what would that be good?
In the time between the kernel eveolved entierly in to a different
direction, *we have* now the device tree the devfs and grock
parition stuff.

> About scanning for partitions I say the same thing I said to Al a few
> days ago:
> Several partitioning schemes exist, and reading partition tables is not
> something a driver should do without getting explicit requests.
> For all we know the disk contents may be completely random.

You are right but the fact is right now we have to do it this way.
And I'm sure some people will start to wimmer about "back-ass compatibility".
But I agree with Larry that unnecessary compatibility
concerns for tools which should be considered as tightly coupled to
the system in question killed partily in the middle of the 90's UNIX
advancement somehow. For Linux this translates to:

1. util-linux
2. modutils
3. pcmci-utils
and so on...

You know that I'm one of the few who is always trying to
push such changes where they make sense. However it always turns out
that the people who don't understand this simlpe fact are just loud
enough to don't be ignored.

> You should offer the list of disks seen to user space, and user space
> should decide which disks have to be investigated, and tell the kernel
> about the partitions it wants to have on these disks.
> That way all knowledge about partitioning, dynamic disks, disk managers
> and the like is removed from the kernel, and moved into partx-type code.

But there is one thing, which isn't prette about the above sheme: races
and atomicity of operations... Well this could be solved
by making the mount system call passing this information as a parameters.
You wouldn't even need to pass any list of disks to user land - we don't
do it right now. Just notify the kernel of the avalibility of a particular
device on hot plug and let mount scan partitions and therelike itself.
It could do it perfectly fine itself.
Since the ATA code was anyway the much uglier part in the game
well there are chances that finally someone will pick up this
idea...

But no matter what right now the changes I did had to be done.

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Andries.Brouwer@cwi.nl wrote:
>>>About scanning for partitions:
>>>Several partitioning schemes exist, and reading partition tables is not
>>>something a driver should do without getting explicit requests.
>>>For all we know the disk contents may be completely random.
>>
> 
>>You are right but the fact is right now we have to do it this way.
> 
> 
> That is OK - I just write to make sure we all agree that this must
> only be an intermediate stage. Scanning for partitions must not be
> something obscure that happens deep down in some driver.
> 
> 
>>>You should offer the list of disks seen to user space, and user space
>>>should decide which disks have to be investigated, and tell the kernel
>>>about the partitions it wants to have on these disks.
>>>That way all knowledge about partitioning, dynamic disks, disk managers
>>>and the like is removed from the kernel, and moved into partx-type code.
>>
> 
>>But there is one thing, which isn't prette about the above sheme: races
>>and atomicity of operations... Well this could be solved
>>by making the mount system call passing this information as a parameters.
>>You wouldn't even need to pass any list of disks to user land - we don't
>>do it right now.
> 
> 
> You see, some disks belong to RAIDs, some disks are in reality very
> slow objects, like compact flash cards or so, some disk have some foreign
> partitioning scheme. There can be all kinds of reasons why we do not
> want to start reading and interpreting any random disk-like device.

Ahhh... wait a moment you are the one who is responsible for
util-linux - wouldn't you care to take a bunch of patches?!

> I know that we used to do this, but it was wrong, so we must slowly move
> to a setup where we do no longer do this.
> 
> So, user space is started on a ramdisk or so, and gets parameters
> rootdev=, rootpttype=, rootpartition=, rootfstype=.
> Now it can use rootpttype to scan rootdev, find the partitions,
> find rootpartition, mount it as type rootfstype on /.
> 
> Afterwards the existence of more devices, possibly with partitions,
> becomes of interest, for example because there is a "mount -a" somewhere.
> Here userspace needs a list of available devices. Maybe /proc/partitions.

/etc/vfstab, /etc/mtab -  are conceptually just fine.

No need to inevent here. No need to do the book keeping in kernel.
passwd doesn't need /proc/users too and many people just forget that
we are still on a UNIX like system.
The only case which deserves special treatment is the parition
where / resides.

Re: [PATCH] 2.5.18 IDE 73

[Andries.Brouwer]

>> About scanning for partitions:
>> Several partitioning schemes exist, and reading partition tables is not
>> something a driver should do without getting explicit requests.
>> For all we know the disk contents may be completely random.

> You are right but the fact is right now we have to do it this way.

That is OK - I just write to make sure we all agree that this must
only be an intermediate stage. Scanning for partitions must not be
something obscure that happens deep down in some driver.

>> You should offer the list of disks seen to user space, and user space
>> should decide which disks have to be investigated, and tell the kernel
>> about the partitions it wants to have on these disks.
>> That way all knowledge about partitioning, dynamic disks, disk managers
>> and the like is removed from the kernel, and moved into partx-type code.

> But there is one thing, which isn't prette about the above sheme: races
> and atomicity of operations... Well this could be solved
> by making the mount system call passing this information as a parameters.
> You wouldn't even need to pass any list of disks to user land - we don't
> do it right now.

You see, some disks belong to RAIDs, some disks are in reality very
slow objects, like compact flash cards or so, some disk have some foreign
partitioning scheme. There can be all kinds of reasons why we do not
want to start reading and interpreting any random disk-like device.

I know that we used to do this, but it was wrong, so we must slowly move
to a setup where we do no longer do this.

So, user space is started on a ramdisk or so, and gets parameters
rootdev=, rootpttype=, rootpartition=, rootfstype=.
Now it can use rootpttype to scan rootdev, find the partitions,
find rootpartition, mount it as type rootfstype on /.

Afterwards the existence of more devices, possibly with partitions,
becomes of interest, for example because there is a "mount -a" somewhere.
Here userspace needs a list of available devices. Maybe /proc/partitions.

Andries

Re: [PATCH] 2.5.18 IDE 73

[Andries.Brouwer]

    Ahhh... wait a moment you are the one who is responsible for
    util-linux - wouldn't you care to take a bunch of patches?!

Of course - improvements are always welcome.
(But I try to be slightly more careful than you are.
Util-linux runs on all libc's and all kernels, from libc4 to glibc2
and from 0.99 to 2.5. So, changes must be compatible.)

    No need to inevent here. No need to do the book keeping in kernel.

Some need. Things like mount-by-label want to know what partitions
exist in order to look at the labels on each.
Yes, we really need a list of disk-like devices.
The gendisk chain.

Andries

Re: [PATCH] 2.5.18 IDE 73

[David Woodhouse]

On the subject of blacklists -- when downgrading the speed of a drive 
because it's found a blacklist, or indeed for any other reason, please 
_print_ the reason for doing so. 

I have drives which work fine at UDMA66, but which some kernels randomly 
refuse to configure above UDMA33 without telling me why. 

Basically, any time you run a drive at a transfer speed lower than the 
minimum of the drive's and host's listed capabilities, you should say why 
you're doing so. 

--
dwmw2

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

David Woodhouse wrote:
> On the subject of blacklists -- when downgrading the speed of a drive 
> because it's found a blacklist, or indeed for any other reason, please 
> _print_ the reason for doing so. 
> 
> I have drives which work fine at UDMA66, but which some kernels randomly 
> refuse to configure above UDMA33 without telling me why. 

Which are those ones on which controller configuration?

> 
> Basically, any time you run a drive at a transfer speed lower than the 
> minimum of the drive's and host's listed capabilities, you should say why 
> you're doing so. 

Sure just let do one steop after other OK.

Re: [PATCH] 2.5.18 IDE 73

[Bartlomiej Zolnierkiewicz]

> On the subject of blacklists -- when downgrading the speed of a drive
> because it's found a blacklist, or indeed for any other reason, please
> _print_ the reason for doing so.
> (...)

fully agreed, already discussed with Martin
things are going slow because first I clean this fsking mess
then add new stuff

greets
--
bkz

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Andries.Brouwer@cwi.nl wrote:
>     Ahhh... wait a moment you are the one who is responsible for
>     util-linux - wouldn't you care to take a bunch of patches?!
> 
> Of course - improvements are always welcome.
> (But I try to be slightly more careful than you are.
> Util-linux runs on all libc's and all kernels, from libc4 to glibc2
> and from 0.99 to 2.5. So, changes must be compatible.)

Having them compatible acroess an insane range of kernels
is a nice but futile exercise.
Perhaps this partly explains why:

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.

>     No need to inevent here. No need to do the book keeping in kernel.
> 
> Some need. Things like mount-by-label want to know what partitions
> exist in order to look at the labels on each.
> Yes, we really need a list of disk-like devices.
> The gendisk chain.

No I don't see that point. Data which has to be persistant across
reboots is simple data which has to reside on disk. That's the
way it is in UNIX (PalmOS to name an example).
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.
After all kudzu is performing nearly the whole job for anything else
except disks anyway for example.

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

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.

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Andries.Brouwer@cwi.nl wrote:
>     > Of course - improvements are always welcome.
>     > (But I try to be slightly more careful than you are.
>     > Util-linux runs on all libc's and all kernels, from libc4 to glibc2
>     > and from 0.99 to 2.5. So, changes must be compatible.)
> 
>     Having them compatible acroess an insane range of kernels
>     is a nice but futile exercise.
>     Perhaps this partly explains why:
> 
>     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.
> 
> If you do the kernel ATA stuff, I'll take care of util-linux.

Well that's actually a deal :-).

> (Does it need more utilities? Probably those are in some other package.
> Sometimes stuff is added, but not very often. However, your suggestions
> are welcome.
> Do the vendors add patches? Half of that is vendor extensions, that is
> their business. Half of that is their stupidity. They blindly copy the
> patches other vendors apply "it is a patch - must be an improvement";
> sometimes I have to reject the same buggy patch more than a dozen times.
> When I ask for the reason of a patch, they don't know themselves.)

Well somehow I have partly to agree. But however having a way to
exclude network devices from mounting during mount -a is *very* usefull,
becouse failing NFS servers will sometines prohibit your watchdog
triggered reboot to happen for example!

Or not doing swapon twice and beeing silent about it - just good
UNIX habit the user requested it to go on - well it's on, so all
is fine, no error in this.

I can stuff together what I think is usefull however...

> 
>     >     No need to invent here. No need to do the book keeping in kernel.
>     > 
>     > Some need. Things like mount-by-label want to know what partitions
>     > exist in order to look at the labels on each.
>     > Yes, we really need a list of disk-like devices.
>     > The gendisk chain.
> 
>     No I don't see that point. Data which has to be persistant across
>     reboots is simple data which has to reside on disk. That's the
>     way it is in UNIX (PalmOS to name an example).
> 
> Maybe you never heard of mount-by-label?
> 
> Andries


Urhg? I did of course hear about them!


~# ssh kozaczek
root@kozaczek's password:
Last login: Thu May 30 14:37:32 2002 from 10.0.0.1
cd [root@kozaczek root]# cd /etc
[root@kozaczek etc]# cat fstab
LABEL=/                 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
/dev/fd0                /mnt/floppy             auto    noauto,owner    0 0
# /dev/loop1            /mnt/1                  auto    noauto,owner    0 0
# /dev/loop2            /mnt/2                  auto    noauto,owner    0 0
none                    /proc                   proc    defaults        0 0
none                    /tmp                    tmpfs   defaults        0 0
none                    /dev/pts                devpts  gid=5,mode=620  0 0
/dev/hda6               swap                    swap    defaults        0 0
[root@kozaczek etc]#


Hmm I didn't check whatever they can be used on swap partitions too.
If not I will fix it right away.

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Alan Cox wrote:
> On Thu, 2002-05-30 at 14:54, Martin Dalecki wrote:
> 
>>I don't use and don't care about devfs - it's a misconception in my opinnion.
> 
> 
> Yes but there are lots of other opinions. And it was just one of several
> examples of why you were proposing something utterly bogus
> 
> 
> 
>>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.
> 
> 
> Linus has explicitly stated he wants to do this and make all disks
> appear the same and the same place. It actually makes lots of sense. 

LAST WARNING:

Every body out there: watch out to use LABEL= in /etc/fstab or you will
not be able to reboot between 2.4 and 2.5 soon!

Things which have to be done in front:

1. Extract device registration from SCSI code.

2. Let the ATA/ATAPI code hook up on it. (ide-cs is the most difficult one.)

3. Let the old ATA/ATAPI major go down the bin...

Re: [PATCH] 2.5.18 IDE 73

[Andries.Brouwer]

    > Of course - improvements are always welcome.
    > (But I try to be slightly more careful than you are.
    > Util-linux runs on all libc's and all kernels, from libc4 to glibc2
    > and from 0.99 to 2.5. So, changes must be compatible.)

    Having them compatible acroess an insane range of kernels
    is a nice but futile exercise.
    Perhaps this partly explains why:

    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.

If you do the kernel ATA stuff, I'll take care of util-linux.

(Does it need more utilities? Probably those are in some other package.
Sometimes stuff is added, but not very often. However, your suggestions
are welcome.
Do the vendors add patches? Half of that is vendor extensions, that is
their business. Half of that is their stupidity. They blindly copy the
patches other vendors apply "it is a patch - must be an improvement";
sometimes I have to reject the same buggy patch more than a dozen times.
When I ask for the reason of a patch, they don't know themselves.)

    >     No need to invent here. No need to do the book keeping in kernel.
    > 
    > Some need. Things like mount-by-label want to know what partitions
    > exist in order to look at the labels on each.
    > Yes, we really need a list of disk-like devices.
    > The gendisk chain.

    No I don't see that point. Data which has to be persistant across
    reboots is simple data which has to reside on disk. That's the
    way it is in UNIX (PalmOS to name an example).

Maybe you never heard of mount-by-label?

Andries

Re: [PATCH] 2.5.18 IDE 73

[Tomas Szepe]

> >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

... tells you exactly nothing, because redhat people would even patch
/bin/true if it could be made to do anything extra.

util-linux build procedure from SlackBuild in slackware-current:

tar xjvf $CWD/util-linux-$VERSION.tar.bz2
cd util-linux-$VERSION
zcat $CWD/util-linux.MCONFIG.diff.gz | patch -E --backup -p1 --suffix=.orig
./configure
make
<snip>

T.

Re: [PATCH] 2.5.18 IDE 73

[Rene Rebe]

Hi.

On: Thu, 30 May 2002 16:01:09 +0200,
    Martin Dalecki <dalecki@evision-ventures.com> wrote:

> Well somehow I have partly to agree. But however having a way to
> exclude network devices from mounting during mount -a is *very* usefull,

mount -a -t nonfs,nocoda,noproc,nodevfs,noshm"

Ever worked for me ...

k33p h4ck1n6
  René

--  
René Rebe (Registered Linux user: #248718 <http://counter.li.org>)
e-mail:   rene.rebe@gmx.net, rene@rocklinux.org
web:      www.rocklinux.org, drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

Re: [PATCH] 2.5.18 IDE 73

[Rene Rebe]

Hi.

On: Thu, 30 May 2002 15:54:50 +0200,
    Martin Dalecki <dalecki@evision-ventures.com> wrote:

> > 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:

DevFS is at least used by ROCK Linux and Mandrake. We never had any
problem with it (and most users really like it's features). So please
do not corrupt it. - I save my time not lising the feature list of
devfs we use ...

k33p h4ck1n6
  René

--  
René Rebe (Registered Linux user: #248718 <http://counter.li.org>)
e-mail:   rene.rebe@gmx.net, rene@rocklinux.org
web:      www.rocklinux.org, drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

Re: [PATCH] 2.5.18 IDE 73

[Linus Torvalds]

On 30 May 2002, Alan Cox wrote:
>
> > 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.
>
> Linus has explicitly stated he wants to do this and make all disks
> appear the same and the same place. It actually makes lots of sense.

It should be a lot easier these days, and we should be fairly close.

A device driver should really _never_ see a "device number". It should see
a request queue and a disk/controller index, so that we can arbitrarily
map different device numbers to different devices (or sometimes to the
_same_ device).

But yes, there are lots of device drivers that right now use the device
number to get the disk/controller index by themselves, so right now the
minor/major numbers mean a bit too much.

		Linus

Re: [PATCH] 2.5.18 IDE 73

[Linus Torvalds]

On Thu, 30 May 2002, Martin Dalecki wrote:
>
> LAST WARNING:
>
> Every body out there: watch out to use LABEL= in /etc/fstab or you will
> not be able to reboot between 2.4 and 2.5 soon!

Absolutely not, Martin. We need to have people be able to upgrade easily,
we're already scaring away too many people from this.

> 1. Extract device registration from SCSI code.
>
> 2. Let the ATA/ATAPI code hook up on it. (ide-cs is the most difficult one.)
>
> 3. Let the old ATA/ATAPI major go down the bin...

The minor/major numbers should stay the same, they are just "mappings".
Device drivers shouldn't even care, and in fact we should aim for a setup
where we have a new cleaned-up "disk major", but at the same time we
should support the old major/minors so that people can easily use the same
disk images across different kernel versions.

That should be fairly easy to do, by just making sure that we (a) remove
the kdev_t from "struct request", (b) replace it with a controller and
disk index and (c) make "open()" do some fairly trivial mapping and save
that mapping in the "bdev", so that make_request() and friends can
trivially just fill in the data.

Voila, end of minor/major problems, and you can suddenly do things like
show the _same_ device on many minor/major numbers (so that you can have
it _both_ on a backwards-compatible place _and_ a new cleaned-up place).

And the device drivers wouldn't ever even _know_ what device number the
user saw on disk was.

		Linus

Re: [PATCH] 2.5.18 IDE 73

[Alan Cox]

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.

> 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
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.

Alan

Re: [PATCH] 2.5.18 IDE 73

[Wichert Akkerman]

In article <3CF62F2A.6030009@evision-ventures.com>,
Martin Dalecki  <dalecki@evision-ventures.com> wrote:
>rpm -i util-linux-xxx.src.rpm
>
>and count the patches yourself.

That is just RedHat and not a good indication of code quality at all,
just of how many patches RedHat thinks they should use.

You really should compare with other distributions before even thinking
about making such statements. Debian for example has almost no patches
to util-linux (mostly some changes for crypto support).

Wichert.


-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@wiggy.net                   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: [PATCH] 2.5.18 IDE 73

[Andries.Brouwer]

> LAST WARNING:

> Every body out there: watch out to use LABEL= in /etc/fstab or you will
> not be able to reboot between 2.4 and 2.5 soon!

Funny. I hope you realize that there are lots of filesystems out there
that do not support a LABEL=.

Andries

Re: [PATCH] 2.5.18 IDE 73

[Alan Cox]

On Thu, 2002-05-30 at 14:54, Martin Dalecki wrote:
> I don't use and don't care about devfs - it's a misconception in my opinnion.

Yes but there are lots of other opinions. And it was just one of several
examples of why you were proposing something utterly bogus


> 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.

Linus has explicitly stated he wants to do this and make all disks
appear the same and the same place. It actually makes lots of sense. 

 

Re: [PATCH] 2.5.18 IDE 73

[Martin Dalecki]

Linus Torvalds wrote:
> 
> On Thu, 30 May 2002, Martin Dalecki wrote:
> 
>>LAST WARNING:
>>
>>Every body out there: watch out to use LABEL= in /etc/fstab or you will
>>not be able to reboot between 2.4 and 2.5 soon!
> 
> 
> Absolutely not, Martin. We need to have people be able to upgrade easily,
> we're already scaring away too many people from this.
> 
> 
>>1. Extract device registration from SCSI code.
>>
>>2. Let the ATA/ATAPI code hook up on it. (ide-cs is the most difficult one.)
>>
>>3. Let the old ATA/ATAPI major go down the bin...
> 
> 
> The minor/major numbers should stay the same, they are just "mappings".
> Device drivers shouldn't even care, and in fact we should aim for a setup
> where we have a new cleaned-up "disk major", but at the same time we
> should support the old major/minors so that people can easily use the same
> disk images across different kernel versions.
> 
> That should be fairly easy to do, by just making sure that we (a) remove
> the kdev_t from "struct request", (b) replace it with a controller and
> disk index and (c) make "open()" do some fairly trivial mapping and save
> that mapping in the "bdev", so that make_request() and friends can
> trivially just fill in the data.
> 
> Voila, end of minor/major problems, and you can suddenly do things like
> show the _same_ device on many minor/major numbers (so that you can have
> it _both_ on a backwards-compatible place _and_ a new cleaned-up place).
> 
> And the device drivers wouldn't ever even _know_ what device number the
> user saw on disk was.

I was more thinking along the way of the way ide-scsi is highjacking the
SCSI major numbers becouse the above scheme you describe would basically
mean the we just reinvent different major/minor numbers with just new names
"controller_index", and "disk_index" where due to the driver dispatching issues
the whole IDE mess would still just preveal under the hood.
But the goal should be more along the way of trying to
actually remove the usage of those arbitrary values all around inside the
kernel.

Plese note as well that there are other IDE alike interfaces which basically
already do the same: USB solidstate, and ParPort attached IDE disks come
first in to mind.

So it's absolutely worthwhile to extract the SCSI major number
registration code and to reuse it as a generic kind of thing.
At least it would relief the dependance of the above drivers on the
SCSI code. Of course here it would make much sense to preserve some
kind of double access to the IDE stuff. Alternatively *this*
could be indeed handled by a kind of generic mapping on
device open path, since basically those major numbers would
be obsoleted, but this is just a second tought. (Yes indeed LABEL isn't
supported on quite a lot of filesystems, so one can't hope
of it to resolve the beckward compatibility or dual boot issue.)

Anyway I'm looking at the ugly childs in blk.h alreay, so
basically the DEVICE_NR macro definitions show where once would have
to do go look after.

Re: [PATCH] 2.5.18 IDE 73

[Denis Vlasenko]

On 30 May 2002 13:09, Rene Rebe wrote:
>     Martin Dalecki <dalecki@evision-ventures.com> wrote:
> > Well somehow I have partly to agree. But however having a way to
> > exclude network devices from mounting during mount -a is *very* usefull,
>
> mount -a -t nonfs,nocoda,noproc,nodevfs,noshm"
>
> Ever worked for me ...

#man mount
...
	For example, the command:
        	mount -a -t nomsdos,ext
	mounts all file systems except those of type msdos and ext.
...

It says you shouldn't repeat 'no' prefix. 
--
vda