Subject: readdisklabel() question
To: None <tech-kern@NetBSD.ORG>
From: Alan Perry <alanp@pacific.Eng.Sun.COM>
List: tech-kern
Date: 12/03/1996 14:17:17
Just joined this mailing list, though I have been on port-sparc for a while.

I have been working on an implementation of NTFS for NetBSD (using sparc as
the reference platform), but in order to get this to work, I have to
muck with readdisklabel() to get it to read the DOS partition table.
What I have to do is pretty simple, but when I started looking at
what some of the callers of readdisklabel() do, I started getting a little
confused and I was hoping for some help understanding what is going on.

readdisklabel() is passed a pointer to a disklabel structure, which it is
supposed to fill in.  readdisklabel() does not seem to fill in every
field and I was trying to determine which ones I could ignore.  Using
just the DOS partition table to determine how to fill in a BSD disklabel
is not fun :-(

However, when I started looking at the callers of readdisklabel(), I was
surprised to discover that the callers do not use it in a consistent
way.  Some callers fill in many of the fields of the disklabel that it
passes to readdisklabel() and do little with it afterward (sd.c) while
others do little with the disklabel structure before the call, and then
use the returned disklabel to set other fields (sparc/dev/xd.c).  When
the sd driver sets a bunch of geometry info in the disklabel structure
and then calls readdisklabel(), if the partition has a Sun disklabel, all
that geometry info gets clobbered.  (so, why does sd do it?)  On the
other hand, when I am trying to make a BSD disklabel out of a DOS
partition table, having all that geometry info pre-filled is nice.
Unfortunately, not all the readdisklabel() callers do that.

Which set of callers to readdisklabel() are correct?