Index: [thread] [date] [subject] [author]
  From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Wed, 24 Feb 1999 14:57:28 +0000

Re: Load-time parameters

becka@rz.uni-duesseldorf.de wrote:
> 
> > > 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.

Yes, that makes good sense as an implementation for the Linux kernel.
We should still have something like the kgi_subparam system as the
API towards drivers though.

Driver components will be much cleaner if the KGI system component
asks the driver components for a structure of parameters (with
default valuse already filled in by the driver component) and fills
in the values that the user specified. It also makes the API independent
of the implementation.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

Index: [thread] [date] [subject] [author]