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 Fri, 4 Sep 1998, Richard Henderson wrote:
> On Thu, Sep 03, 1998 at 11:34:46PM +0300, Alon Ziv wrote:
> > Module settings will be accessed, just prior to module removal, by having
> > rmmod inspect kernel memory for the relevant variables. It can be done by
> > having rmmod load the object module, gather the list of variables to
> > inspect, and access them via /dev/kmem.
>
> As Alan mentioned, this is unthinkably bad. It is, however,
> trivial to add another query_module(2) function to read a
> parameter block.
>

I've already been more-or-less convinced about this... The kmem approach
is wide open to races.

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').
It has the advantage of being easier to use, and being textual (binary
data is too often misparsed); but I'm not sure how easy it is to support.

> > (BTW, this will mean that we need
> > to remove the automatic reaping logic from the kernel, and move it to a
> > userspace daemon; this isn't all that hard, and provides added benefits
> > like per-module autoremoval timeout. And anything that moves code to
> > userland is a win...)
>
> Careful. One of the reasons the auto-reap stuff is in the kernel
> is race conditions. Furthermore, it is linear for the kernel to
> walk the list of modules, whereas it is quadratic for userspace
> to do the same.
>

Why? I believe if we just add QM_ALL_INFO, and make it also clear the
MOD_VISITED flags, we can then compute the list of modules to reap in
userspace and delete them. Sure, we'll also need to inform delete_module
that it should ignore our request if the module has been visited again;
but it's a small payment, and we gain the ability for more complex reaping
policies (e.g., we may decide never to remove the ppp modules while pppd
is running, even if it's waiting for callback with the tty closed...)

> > * The MODULE_PARM type syntax should be extended, providing also an
> > ability for specifying min/max values for integral types (maybe even a
> > comma-separated list of allowed values) and `hints' as to input format
> > (e.g., `MODULE_PARM(io,"i 0x378,0x388 : 0x%x")').
>
> Why would you care about input format? But ranges and lists of values
> aren't too odious.
>

Input format is useful for a userspace kernel configuration tool, that
asks the user to input parameter values (see Red Hat's kernelcfg). Sure,
it's just a nice-to-have feature, but--- if the info isn't in the
MODULE_PARM syntax, it has to be put somewhere else... And we may lose
sync.

-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.105 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site