Subject: Re: Removig generic optstr_get
To: Quentin Garnier <>
From: Bill Studenmund <>
List: tech-kern
Date: 10/24/2006 22:21:10
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=
> > > > 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=
> > 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.

Take care,


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

Version: GnuPG v1.4.3 (NetBSD)