Subject: Re: Removig generic optstr_get
To: Quentin Garnier <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 10/24/2006 22:21:10
Content-Type: text/plain; charset=us-ascii
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=
> > > > than Multiboot one day.)
> > >=20
> > > And proplib will still be there for that.
> > I think the question is more about what will be passing us the info to=
> > parse. If we can ensure it will be in a proplib format, you're right; w=
> > don't need this other code. If however it might be in a "a=3Db c=3Dd" f=
> > this code is useful.
> 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.
> 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=
a great way to get info into proplib.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----