Re: [PATCH] ide-disk.c rev 1.13 killed CONFIG_IDEDISK_STROKE

From: Andries.Brouwer@cwi.nl
To: B.Zolnierkiewicz@elka.pw.edu.pl, aebr@win.tue.nl
Cc: alan@lxorguk.ukuu.org.uk, andersen@codepoet.org,
	linux-kernel@vger.kernel.org, marcelo@conectiva.com.br
Subject: Re: [PATCH] ide-disk.c rev 1.13 killed CONFIG_IDEDISK_STROKE
Date: Thu, 7 Aug 2003 11:57:49 +0200 (MEST)	[thread overview]
Message-ID: <UTC200308070957.h779vnj22394.aeb@smtp.cwi.nl> (raw)

    > The part I most object to are things like
    >
    > > +    id->lba_capacity_2 = capacity_2 = set_max_ext;
    >
    > There have been many problems in the past, and it is a bad idea to add
    > more of this. We should be eliminating all cases.

    What problems?  This reflects real change in drive's identify
    and I think should be replaced by rereading drive->id from a drive.

In order to be able to troubleshoot problems we need to be able
to reconstruct the information involved.

One part is the disk identity info that existed at boot time.
It was read by the kernel, and stored. It is returned by the
HDIO_GET_IDENTIFY ioctl, as used in e.g. hdparm -i.

There is also the current disk identity info.
It is found by asking the disk now, and is returned by e.g. hdparm -I.

    > We have info from BIOS, user, disk etc and conclude
    > to a certain geometry.

    I can't spot place when we get info from a BIOS.

See arch/i386/boot/setup.S
(I ripped out ide-geometry.c recently, so the use has diminished.)

    > Sneakily changing what the disk reported is very ugly. I recall a case
    > where a disk bounced between two capacities because the value that this
    > computation concluded to was not a fixed point. Also, the user gets an
    > incorrect report from HDIO_GET_IDENTITY.

    User gets correct report from HDIO_GET_IDENTIFY as drive's identify was
    really changed.  Moreover HDIO_GET_IDENTIFY needs fixing to actually
    reread drive->id from a drive (similarly like /proc identify was fixed).

There are at least two objections.
First: we do not want the new identity, we want the old.
Second: if we ask the disk for identity again, you'll see that
more than this single field was changed.

If the user only wanted to know the current max size then there are
other means, like BLKGETSIZE.

    > So, the clean way is to examine what the disk reported, never change it

    Even if disk's info changes?  I don't think so.

Yes. The disk geometry data that we use is drive->*
What the disk reported to us is drive->id->*.

Andries