lkml.org 
[lkml]   [1998]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Module Ideas: Persistence, PnP, and more...
On Sat, 5 Sep 1998, Jamie Lokier wrote:
> On Sat, Sep 05, 1998 at 11:06:38AM +0300, Alon Ziv wrote:
> > I, personally, prefer a /proc interface that will print, for each settable
> > parameter, its contents in the same format used on insertion (e.g.,
> > `cat /proc/module-params/sound' will result in `irq=8 volume=222').
>
> That's a nice one, and probably is doable.
>
> The obvious implementation would print out the values passed initially
> to the module as parameters. For things like sound drivers, I doubt
> they update the configuration data whenever the mixer settings change.
>
No, but this is fixable.

> There would also need to be a lock, so when drivers update this
> information in their configuration blocks, the /proc interface doesn't
> output inconsistent information.
>
Yeah, this is a bit of a snag. Maybe each driver's configuration block
should begin with a spinlock for this...
(I don't see any chance for a race in UP, but maybe I'm wrong?)

> How about a combination of this and Alan's __persistent suggestion?
> /proc/module-params/sound outputs:
>
That's what I had in mind myself, with very slight differences.

My idea was to add another macro in the drivers:

MODULE_SETTING(var,type,arraylen,endval)

which puts in the __persistent section the var name, the type, and a
pointer to it. Type strings here will probably be very restrictive, as
the /proc reading code should parse them. (We also need a way to get a
pointer to the first persistent value and the last one; these may go in
the module struct, probably, but then we'll still have a problem with
compiled-in drivers).

The /proc code will just read the variable names and types, and use these
(and the value pointer) to format the output. It will need the
aforementioned magic to locate the start of the table and its length.

And, if we need something that is truly version-dependent, we'll just
declare it as a `byte buffer' to the /proc interface; we'll then store a
version number in the first word of the struct, and when initializing, if
this word isn't correct, we'll just ignore the rest. (Of course, this
will require teaching the `byte buffer' type to insmod also...)

And so, we'll have something like the following:

# cat /proc/module-params/sound
irq=8
volume=222
io=768
dma=1,6
mixer=0x19,0x98,0x09,0x05,0x12,0x13,0x00,0x11
#

The chief changes from your idea are that *only* data declared as
`persistent' is output this way, and that the version thing is moved to
normal logic. I think this makes the design quite simple.

The one thing I don't like about my idea is that for every setting, we'll
need three lines like

int dma[NR_CARDS] = { [0 ... NR_CARDS-1] = -1 };
MODULE_PARM(dma, "1-" __MODULE_STRING(NR_CARDS) "i 1-16");
MODULE_SETTING(dma, 'i', NR_CARDS, -1);

there's needless duplication between the MODULE_PARM and MODULE_SETTING;
maybe we can just have MODULE_DESC have the same syntax as MODULE_PARM,
and the /proc code will just read the string description of the
parameter... Although this may be quite complex.

-az

------------------------+---------------------------------------------
. __ | Phone: 03-5340753 (home), 03-9685882 (work)
_| / | email: alonz@usa.net
/ | /_ Alon Ziv | smail: 33 Ha-Rama St., Ganey Tiqwah 55900
------------------------+---------------------------------------------
<<<(((this place reserved for that ultra-wise oneliner I haven't found.)))>>>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.027 / U:2.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site