--gKMricLos+KVdGMg
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 <dan@geek.com.au> 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.
>=20
> 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=
=20
enough code to _need_ this trick though.

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

Take care,

Bill

--gKMricLos+KVdGMg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFP3+YWz+3JHUci9cRAqJXAJ4yzIXcUAEvzR+qStaWvOPSLsue5gCdFjtc
bYuU94UAIzb/etxlE8IeNNU=
=ouOK
-----END PGP SIGNATURE-----

--gKMricLos+KVdGMg--