On Thu, 7 Aug 2003 Andries.Brouwer@cwi.nl wrote:
> From: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
>
> > > > 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
> necessary.
>
> (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.)
There should be no such things.
> 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.]
Yep, I've noticed this too.
> 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.
I know this stuff :-).
> 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.)
Indeed.
> > >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.]
I came to the same conclusion about increased memory usage.
I will fix overwrtitting of drive->id->* by keeping current values in drive->*
(just as you've suggested).
Thanks,
-- 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/
This archive was generated by hypermail 2b29 : Thu Aug 07 2003 - 22:00:38 EST