Subject: Re: Removig generic optstr_get
To: Bill Studenmund <>
From: Quentin Garnier <>
List: tech-kern
Date: 10/25/2006 01:58:58
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> > > On Tue, Oct 24, 2006 at 02:46:18PM +0200, Julio M. Merino Vidal wrote:
> > > > Hello,
> > > >=20
> > > > Objections?
> > >=20
> > > Is there a real need for this change? I would prefer leaving things as
> > > they are now.
> > >=20
> > > (We might want to support richer boot parameters with other boot meth=
> > > 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=20
> parse. If we can ensure it will be in a proplib format, you're right; we=
> don't need this other code. If however it might be in a "a=3Db c=3Dd" for=
> 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.

Think what you want of proplib, but IMO it is a very good compromise for
that kind of work:  it works in a stand-alone environment, and the
kernel already has it.  Also, the API makes it rather easy to produce a
dictionary, so the actual user interface isn't impaired.

Quentin Garnier - -
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

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

Version: GnuPG v1.4.5 (NetBSD)