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:

> From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
>
> > In order to be able to troubleshoot problems we need to be able
> > to reconstruct the information involved.
>
> What problems are we talking about? :-)
>
> I am happy that you think there are no problems.
> I spent a considerable time eliminating.
> On the other hand, if you don't know from experience
> then a simple google search will tell you that this
> has been a very painful area in the past.

Very informative answer, thanks ;-).

> > 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
>
> It helps a little in two ways. One, to help people with fdisk/LILO/..
> disk geometry problems. Two, to investigate new disks.
>
> It is good to have clean data.

Exacty, but I understand it differently.

> Long ago distributions contained privately modified versions of packages.
> Today they use rpms where the pristine sources and the patches are
> clearly visible. Much better.
>
> > 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?
>
> Yes.
>
> drive->id is what the drive says it can do.

Nope, drive->id is what drive says it can do,
but also what it currently does.

> If the kernel is satisfied with that then it just uses this data.
> If the kernel is of the opinion that it also has to check
> what kind of cable, and what kind of controller, then it
> does not change drive->id->* but determines the mode it wants to use
> and writes that to drive->*.

drive->id also reports *current* active mode
(it changes on a drive itself).

> Moreover, drive->id tells you the situation after the BIOS did its setup.
> Sometimes the BIOS knows things the kernel doesnt know. It is good to
> have the information. Destroying information serves no useful purpose.
>
> > > 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.
>
> I am not sure I can parse that.

After issuing SET_MAX_ADDRESS or SET_MAX_ADDRESS_EXT hardware drive->id
is updated and we are using this information, so disk reports to us geometry,
nope?

> -----
> >From "man hdparm"
>
> -i Display the identification info that was obtained
> from the drive at boot time, if available.
> -I Request identification info directly from the
> drive.

This is a show-stopper only for changing HDIO_GET_IDENTITY semantics,
not driver itself (we can have separate drive->boot_id for this).

I am starting to think that drive->id (reflecting actual identity) and
drive->boot_id (saved boot drive->id) is a long-term solution.

--
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.053 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site