From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Wed, 24 Feb 1999 01:00:51 +0100 (MET)

Re: Load-time parameters

> > Alright, then I propose that the new API to get module parameters from the
> > KGI subsystem be as follows:

> > kgi_sint kgi_parm_in_u8  (kgi_card *this, char *name, kgi_u8  *ptr);
> > kgi_sint kgi_parm_in_u16 (kgi_card *this, char *name, kgi_u16 *ptr);
> [snipped more similiar declarations]

Too many IMHO. 

I'd rather suggest to have just a "get-string" function and define
kgi_sprintf/kgi_sscanf to be present. Maybe with a reasonably limited
subset of possible formats.
It's not do hard to write a limited scanf/printf, and it gives full
freedom for parameters.

This is IMHO also what we should do for insmod parms:

Just do something like:

insmod kgicon.o parms="dacspeed=123,blubb=2323,chip=V2,..."

More or less like you do with LILO/kernel.

> This is not good. It produces bloat both in size and cycles, and is
> not well suited for hierarchical systems like Linux sysctl/proc or
> win32 registry.

Do we really need a hierarchical system ? I'd like to KISS and thus
would rather avoid these, as they are hard to represent on non-hierarchical
systems and bloat code there.

> It might require som macro magic if we want to support
> systems like Linux insmod parameters where each parameter must be
> declarated at compile time, it's more flexible than a bunch of
> functions.

IMHO this macro magic isn't too good compatibility wise.

The most basic thing one can pass as parameter is a (set of) strings.

LILO/kernel works this way, shell parameter passing, etc. ...

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =