Subject: Re: disklabel(8) and machdep on-disk structures issues
To: <>
From: David Laight <>
List: tech-kern
Date: 11/07/2003 10:25:37
On Thu, Nov 06, 2003 at 11:38:57PM +0100, Manuel Bouyer wrote:
> [ please reply to tech-kern, unless your anserw is really port-specific ]
> Hi,
> On Fri, Oct 31, 2003 at 05:07:04PM +0100, Manuel Bouyer wrote:
> > 
> > So I propose:
> > - fix next68k disksubr.c to always write a next-compatible disklabel
> >   in addition to the NetBSD disklabel (need to find some space for
> >   the NetBSD disklabel first, shouldn't be too hard).
> > - Fix the sun3 LABELOFFSET, and factor out disksubr.c between sun3, sparc and
> >   sparc64 (with some compat code to look for a NetBSD disklabel at
> >   LABELOFFSET=64 in the sun3 case)
> > - remove #ifdef __sparc__ hack from disklabel(8), and change it to issue
> >   a DIOCWDINFO after writing the disklabel to the raw partition in the
> >   -r/-I case (so that the kernel can convert the label if needed)
> Attached is a patch implementing this. Tested on sparc, sun3 and next68k.
> We now have a sys/dev/sun/disksubr.c, based on sparc/disksubr.c. The
> sparc/disksubr.c and sparc64/disksubr.c differed only by some includes
> (BTW, both #included too much things). sun3/disksubr.c has some more
> differences, especially the groveling code to find a NetBSD disklabel 
> in the first sector. I integrated this in sys/dev/sun/disksubr.c, as fallback
> if no NetBSD or Sun label have been found at the expected place (this will
> ensure that disk writtens with disklabel -r using the wrong Sun3 labeloffset
> will still be readable).
> next68k still doesn't write a NetBSD disklanel; I didn't find a proper place
> for it on disk yet (LABELSECTOR=15 should put it at the end of the NeXT v3
> label, but the machine doens't boot with it ...).
> Comments ?

Maybe leverage the code in subr_disk_mbr.c so that sparc systems can
read disks with MBRs and i386 systems can read sparc disks?
(Clearly there are additional endianness problems....)

The 'hunt the disklabel' in the read path could certainly benefit
from being able to process any disk at all.  Writing could be more tricky!


David Laight: