lkml.org 
[lkml]   [2003]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ide-disk.c rev 1.13 killed CONFIG_IDEDISK_STROKE

On Thu, 7 Aug 2003 Andries.Brouwer@cwi.nl wrote:

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

What problems are we talking about? :-)

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

What is a value of having these two identities
(other than questionable debugging aid which can be implemented
differently)?

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

Yep, this is no longer used.

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

Question remains, what for?

> Second: if we ask the disk for identity again, you'll see that
> more than this single field was changed.

We are updating drive->id for changing DMA modes,
should this be "fixed" as well?

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

Yep, I think BLKGETSIZE should be used for such usages.

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

This is a contradiction if geometry of disk was changed cause
disk reported to us geometry data second time.

--
Bartlomiej


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.029 / U:6.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site