RE: [Bug-hurd] Problem with dev/glue/block.c (Resolution)?

[Brent Fulgham]

I think the problem with the dev/glue/block.c code is
that the "& mask" actions should not be taken when
referencing into the partition table.

When we setup the partition table on boot, we
use the Linux kernel driver "msdos_partition"
function, which in turn calss the "add_partition"
command.

Tracing the operation with a bunch of printk's, I
can see that we go to initialize the partition
at around minor value 63 (which is the first partition
of the slave device).

We check that current_minor & mask (64 & 0x4F) is not
zero (which happens if our current_minor rises above 48
on the master device, or rises past 127 for the secondary
device).  This puts us at "1" (the anding masks the other
bits) and we enter the add_partition, passing a table
value of 64.

add_partition uses the 64 as-is (no masking), and stores
the partition table data at 64+.

When we add the masking in dev/glue/block.c for our
table offset, we incorrectly point ourselves at "1"
(so in effect we are trying to find slave drive
partition "1" at the table location for master drive
partition "1").  Since I have no such drive, I get
an error message.  People without the Hurd on the
primary drive get a message that the file can't be
found.

The Linux driver code does use the "& mask" every time
it displays the drive name:

maj = "hd";

char unit = (minor >> hd->minor_shift) + '0';   // Yields '1'
part = minor & mask;            // This yields "2" rather than "65"
sprintf(buf, "%s%cs%d", maj, unit, part);

Which yields the desired "hd1s2".

I think it was incorrect to add the "& mask" operation to 
our partion table offset.  I suspect that the cause of the
IDE CD-ROM problem is of a different nature.

The reason people with the Hurd on the primary master drive
do not see a problem with the new code is that their primary
slave has major=0, minor=0 and any bit shifts are no-ops.

Could someone review this logic and see if they agree with
me?  Otherwise, I think we should back out the & operators
in the partition table offset calculations.

Thanks,

-Brent