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

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

After issuing SET_MAX_ADDRESS or SET_MAX_ADDRESS_EXT hardware
drive->id is updated

Yes. So far no kernel has asked the disk for an update.
And I don't think we have seen cases where that would have been

(I mean, theoretically it would be possible that the disk reported
at first that DMA was supported, while after SET_MAX_ADDRESS this
no longer is supported, e.g. because of some strange problem that
allows DMA only from/to the first 32GB. In practice we have never seen
such things, I think.)

and we are using this information,
so disk reports to us geometry, nope?

Still difficult to parse.

Let me just say some things. Maybe I answer your question, maybe not,
then ask again, as explicitly as possible.

What geometry stuff do we need? Let me sketch roughly, omitting details.

First, there is drive->{head,sect,cyl}.
If the drive does not know LBA, then we use drive->{head,sect} for
actual I/O. If the drive uses LBA we do not use drive->{head,sect,cyl}
at all. It is a bug when drive->head is larger than 16, or drive->sect
larger than 63.

Secondly, there is drive->bios_{head,sect,cyl}.
This is not what we use, but it is what we report when user space asks.
It is for LILO and fdisk. It is a very difficult question what we have
to answer here, but it is irrelevant for the kernel.

Thirdly, there is the total disk size.
The kernel stores this in drive->capacity{48}.
[Yes, that reminds me - having two values here is unnecessary.
One of my following patch fragments eliminates drive->capacity
so that only drive->capacity48 is left.]
What is actually used as total size, and also reported by BLKGETSIZE,
is the return value of current_capacity(), and it is equal to
drive->capacity48 minus the part used by a disk manager.

The kernel does not directly use id->lba_capacity anywhere, except
in the initial setup, in order to compute drive->capacity*.
(So, changing it does not do anything useful.)

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

Yes, in principle there is nothing wrong with that.

[But I wrote my first operating system on a 4K computer.
Spent hours reducing the size of a driver from 129 to 128 instructions.
Am permanently damaged now, very strongly conditioned against wasting memory.]

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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