Subject: Re: Removig generic optstr_get
To: Julio M. Merino Vidal <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 10/25/2006 08:15:36
Content-Type: text/plain; charset=us-ascii
On Wed, Oct 25, 2006 at 01:15:15PM +0200, Julio M. Merino Vidal wrote:
> On 10/25/06, Daniel Carosone <firstname.lastname@example.org> 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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----