Subject: Re: disklabel(8) and machdep on-disk structures issues
To: Robert Elz <kre@munnari.OZ.AU>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 11/12/2003 17:17:32
On Wed, Nov 12, 2003 at 10:57:16PM +0700, Robert Elz wrote:
> Date: Wed, 12 Nov 2003 12:09:17 +0100
> From: Manuel Bouyer <email@example.com>
> Message-ID: <20031112110917.GB4252@antioche.eu.org>
> | I think this should be the job for a userland tool (a la mbrlabel(8)).
> | The kernel needs to know about native partitions maps for the port, to be
> | able to find the root partition, but we probably don't want to put the
> | knowledge of each partition map of the world in the kernel.
> I agree totally - the kernel needs to know how to find and read as much as
> is required to locate the root (at least).
> But, assuming we have that userland tool that knows how to read/write labels
> for every other port's labels - and that it is also going to run on all those
> other ports (and hence also know how to read/write our label - whatever port
I was think only about read, but yes, it could write too.
> "our" is in this context) I was wondering whether the desire to put the
> writing of the native port labels in the kernel can really be supported?
> It needs to be in the userland tool anyway, so the labels can be written
> on other ports - having it in the kernel as well seems like needless
> duplication of effort, and knowledge. I think I'd have all label writing
> done in a userland tool that can be made as smart (and protective) as needed.
Yes, but my main concern for now it to fix next68k (in the current state
it can't create a bootable disk from scratch) and sun3 (which uses the wrong
labeloffset). I don't have the time to write this userland tool, and this can
be done later.
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
NetBSD: 24 ans d'experience feront toujours la difference