Subject: Re: Removig generic optstr_get
To: Julio M. Merino Vidal <>
From: Bill Studenmund <>
List: tech-kern
Date: 10/25/2006 08:15:36
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 25, 2006 at 01:15:15PM +0200, Julio M. Merino Vidal wrote:
> On 10/25/06, Daniel Carosone <> wrote:
> >On Wed, Oct 25, 2006 at 01:36:25AM +0200, Quentin Garnier wrote:
> >> On Wed, Oct 25, 2006 at 09:17:18AM +1000, matthew green wrote:
> >> >
> >> > you want me to type plists on the command line?
> >>
> >> Yes, please.  Thanks for volunteering.
> >
> >But more seriously, parsing a=3Db c=3Dd strings handed to us by random
> >platform bootloader or environment strings *into* plists in memory,
> >for consumption by MI or almost-MI configuration code, might be a good
> >idea.
> That sounds good, yes.  But in that case, it might be better if the
> conversion was done by the bootloader itself, isn't it?  This way the
> user could be able to manually provide a plist if he wanted to for
> whatever reason (complex data structures that can't be clearly
> expressed as a single "options string"?).

Maybe, maybe not. I think it depends on how we boot.

If we boot with our normal boot process, then yes, I think it actually=20
would make sense to have the bootloader do the conversion. Once the boot=20
loader's done, it's gone, so we won't keep this code resident (i.e. it=20
won't sit in the kernel). To be honest, I don't think we're talking about=
enough code to _need_ this trick though.

The problem is that there are boot processes, like the mutli-boot stuff as=
I understand it, where we don't control the boot process. The kernel just=
starts running as far as we can tell. These boot methods will need the=20
parsing code in the kernel.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.3 (NetBSD)