From dledford@redhat.com Sat Apr 24 18:36:31 1999

    Guest section DW wrote (about extended translation for aic7xxx):

    > This was true for 2.0.* and is still somewhat true for 2.2.6
    > but the precise conditions have changed (and became messier).
    > Two important changes are:
    > 
    > For 2.0.36 giving boot parameters "aic7xxx=extended" would always
    > give you an extended translation. For 2.2.6 this will only work
    > if the driver finds no SEEPROM, but will be ignored otherwise.
    > 
    > For 2.0.36, if the driver did not find a SEEPROM it would
    > always give you an extended translation.
    > For 2.2.6, if the driver did not find a SEEPROM it will
    > only give you an extended translation if you asked for it.
    > 
    > I do not know whether this change was intentional - it seems
    > to me that a driver should do what the user asks in an explicit
    > boot parameter.

    That latest driver allows the SEEPROM to override the user setting since
    it makes no sense to not have them match.

Roughly speaking I agree - it makes no sense in 98% of the cases.
Unfortunately the remaining 2% writes to me with problems and complaints.
I think the driver should never ignore the explicitly given wish
of the user.  This user will only start supplying boot time parameters
when the default does not work. So, it never makes sense to ignore
boot parameters.

    However, it *only* does this when there are no partitions on
    the device, the latest code will always take the geometry used
    in the partition table over its own geometry.

I am very unhappy with such behaviour.

It is a myth that it is possible to derive the geometry used
from the partition table. These days there seems to be a
fairly standard convention that partitions should end on a
cylinder boundary, but many fdisk versions will allow the
user to select arbitrary partition boundaries. Not only Linux
fdisk, but for example also certain Windows NT versions for
the Alpha do this.

And what does "the geometry" mean? You know very well that this
is not a concept that makes sense for SCSI disks. So, it is only
a fiction that makes fdisk and LILO happy. And for fdisk it is
pure fiction, it really makes no difference what garbage you write
in the geometry field as long as you have a Linux-only system.
But for LILO it has some real significance: it is the geometry
that will allow successful interaction with the BIOS at boot time.

The SCSI driver may know what the on-board BIOS of the card will do.
But what the BIOS will do is surely not dependent on disk contents.
So any SCSI driver that returns a geometry deduced from looking at
the disk is *broken*. LILO and fdisk read the partition table
themselves. They do not need anybody else to tell them what is there.

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/