: The main problem is that the "invented" geometery should correspond to the
: values provided by the BIOS, or other OS driver, or there is little point
: in having the system call.
: What my patch did is access a routine that would scan the partition table
: and usually guess right about the disk geometery - since most schemes
: would end on cylinder boundaries, the "end" values would have the total
: number of sectors and heads as perceived by the BIOS.
: The routine (in linux/drivers/scsi/scsicam.c) could be cloned or adapted
: or the function implemented in fdisk (all flavors) and lilo.
You seem to contradict yourself. On the one hand you want to get
values given by a controller, or by the BIOS, and that is what Linux
does right now, and on the other hand you suggest a patch skipping
BIOS or controller information and calling scsicam.c:scsicam_bios_param().
But this latter routine is entirely bogus - it does not ask BIOS or
controller, but reads the partition table and tries to guess geometry
information by picking some random partition and hoping that the
end_sector and end_head fields will describe the number of sectors
and heads.
Thus, if the disk is new and does not contain a partition table,
the patch will almost certainly yield the wrong geometry.
When the disk is larger than 1024 cyls nobody knows what will be
in the end_sector and end_head fields.
With a disk smaller than 1024 cyls that has a number of blocks
that is not an integral multiple of the number of cylinders
then the patch will yield the wrong geometry if the last partition
goes up to the end of the disk.
Otherwise, scsicam_bios_param() may well give the right answer.
I think such heuristics fit better in a conversational fdisk
than in the kernel. On the other hand, we might add a bootparameter
or ioctl to the kernel, telling it what to return for a HDIO_GETGEO
ioctl on a given SCSI disk.
Andries