While designing some disk utilities, I found it rather
inconvenient that what the kernel gives back with the
HDIO_GET_IDENTITY ioctl differs in obscure architecture-
dependent ways from what one reads directly from disk.
Looking at the kernel code, I find 26kB of byteswapping
source code just for IDE identify data.
If I am not mistaken one can save 25kB by using
a single boolean that describes whether the
disk controller stores the data (256 shorts)
with high or with low order byte first.
Maybe for all architectures this is low order byte first,
and if this is true we can declare hd_driveid as
unsigned char [512], and no architecture-dependent
byteswapping is required anymore.
(Provided that one picks up the values in a decent way,
not by typecasting, but just by computing p[0]+(p[1]<<8).)
I write this mainly in the hope to get some feedback
from ppc people. The current code is very messy, with
separate per-model identify_drive_data_byteswap routines.
Moreover, I believe that the current code is broken
(where the current struct hd_driveid has chars).
Who wrote this code? Is there a special reason
for these complications?
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:19 EST