> No, only the FreeBSD sysinstall, fdisk and boot programs use the
> BIOS geometry.  The drivers don't use it, but they attempt to
> determine it (so that they can reporte it to sysinstall and fdisk)
> by looking at the contents of the DOS partition table.

I think you're confused, or perhaps only talking about SCSI disks.
>From sys/i386/boot/biosboot:

	/* Pick up the story from the Bios on geometry of disks */

	for(ret = 0; ret < N_BIOS_GEOM; ret ++)
		bootinfo.bi_bios_geom[ret] = get_diskinfo(ret + 0x80);

and then from sys/i386/isa/wd.c, in wdgetctlr():

		if (du->dk_unit == bootinfo.bi_n_bios_used) {
			du->dk_dd.d_secsize = DEV_BSIZE;
			du->dk_dd.d_nsectors =
			    bootinfo.bi_bios_geom[du->dk_unit] & 0xff;
			[etc.]
			bootinfo.bi_n_bios_used ++;
			return 0;
		}

I haven't examined the SCSI code get.

> Of course, this can only work if the partition table is nonempty,
> and it often gives the wrong results unless the partition table
> follows defacto standard conventions.

I added code to the NetBSD fdisk to do this kind of heuristic
calculation, and it does not rely on any de facto partition table
conventions.  It treats each partition table entry as an equation, and
attempts to find non-degenerate equations in the partition table which
will yield the number of sectors per track and the number of heads.

Arguably, the code should have gone into the disk drivers (so that
disklabel can work properly), but I'd rather see the drivers use the
BIOS geometry.

> 		# The following self-referential step is required
> 		# because many modern SCSI BIOSes attempt to determine
> 		# the geometry by looking at the partition table.

So what do they do if there's no partition table?  They have to return
something; as long as it's a valid geometry for the disk, you should
be able to use it and the next time the BIOS is queried for the disk
geometry, it should return the same thing.