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 <bouyer@antioche.eu.org>
>     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
--