--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 25, 2006 at 01:58:58AM +0200, Quentin Garnier wrote:
> On Tue, Oct 24, 2006 at 03:53:13PM -0700, Bill Studenmund wrote:
> > On Wed, Oct 25, 2006 at 12:44:52AM +0200, Quentin Garnier wrote:
> > > On Tue, Oct 24, 2006 at 10:20:49PM +0200, Pavel Cahyna wrote:
> > > >=20
> > > > (We might want to support richer boot parameters with other boot me=
thods
> > > > than Multiboot one day.)
> > >=20
> > > And proplib will still be there for that.
> >=20
> > I think the question is more about what will be passing us the info to=
=20
> > parse. If we can ensure it will be in a proplib format, you're right; w=
e=20
> > don't need this other code. If however it might be in a "a=3Db c=3Dd" f=
ormat,=20
> > this code is useful.
>=20
> Linux is a proof that most of the information we might want to pass to
> the kernel doesn't really fit in a list of name=3Dvalue items.
>=20
> Whatever user interface is used in the bootloader(s) to enter
> information, it is for the better if the kernel side of the issue is
> done once and for all.

I don't disagree for generic processing. But we really have to take the=20
info in the format the bootloader gives it to us, and we can only make=20
_our_ bootloaders pass in proplib. Others will pass in what they will.

Put another way, I think the library/routines we started talking about are=
=20
a great way to get info into proplib.

Take care,

Bill

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

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

iD8DBQFFPvRGWz+3JHUci9cRAuohAJ9fQjwKoWKKxUsHbfknvFFzjBBcxgCeJWSz
dPRJ4dpyM0UUVkfWkWIPvXQ=
=2z+D
-----END PGP SIGNATURE-----

--oyUTqETQ0mS9luUI--