[lkml]   [1998]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectModule Ideas: Persistence, PnP, and more...

    Following are some ideas I've been playing with for enhancing module
    support a bit more. These ideas are 2.3 stuff, but I'd like some comments
    on them before I'm too deeply coding... Especially from Richard (as I'm
    radically changing modutils) and from Alan (as my ideas concern PnP, which
    he's mentioned as a 2.3 goal).

    So, here goes.

    1. Persistence

    One of the major pitfalls with current module support is that user
    settings are not saved between uses of a module. This includes both
    `initialization' settings (set using `parm=xxx' at insmod time) and
    runtime-tunable settings (such as sound volume).

    To get over this, I suggest a completely user-space approach.

    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. (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...)

    The persistence mechanism itself will be implemented by having rmmod save
    the settings it's read into some file (probably indexed by module name);
    modprobe will consult this file, in addition to /etc/modules.conf, to
    determine module parameters when it invokes insmod.

    One caveat on this approach is that any state saved must be settable by
    insmod parameters; still, I think this is acceptable.

    (An aside: i'm not all that sure that rmmod should read the settings
    itself; maybe it's a job for another program. This program can then be
    used both from the userspace reaping daemon and from the shutdown scripts
    to save the state on powerdown).

    2. Plug-and-Play support

    To properly support PnP, we need a method for userspace `bus managers' to
    identify drivers by their IDs on the bus, and to configure them.

    To solve the identification problem, I suggest that depmod should be
    changed to also print a file mapping the device IDs found inside modules
    (specified using the MODULE_SUPPORTED_DEVICE macro) to module names (this
    may even be some sort of `aliases' file, in the form `alias
    pci-id-1274-1371 es1371' or `alias pcmcia-id-3Com_Corporation-3C589
    3c589_cs'). modprobe will be able to map these identifiers to the correct

    The configuration problem can be solved, again, without too many problems.
    The bus manager should be able to ask modprobe what it's insmod parameters
    will be given a specific device id (e.g., `modprobe -q
    pcmcia-id-3Com_Corporation-3C589' will get a reply like
    `/lib/modules/2.3.11-2/sound/3c589_cs irq=22'). The bus manager will also
    use modinfo to get the list of parameters supported by a module; we'll
    need to make all modules support uniform names for some parameters, so the
    managers will recognize the neccessary ones (like `irq' and `io').

    3. Additional modinfo

    I suggest to add the following information into each module:

    * _All_ modules should have, at least, a MODULE_DESCRIPTION.

    * All module parameters should use MODULE_PARM, preferrably together with
    MODULE_PARM_DESC. (Also, as mentioned above, common parameters should
    have conforming names).

    * 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")').

    Some of these changes are required for implementing my PnP suggestion; the
    syntax extension of MODULE_PARM will allow auto-generation of Red Hat's
    module-info files (or maybe even replacing their use altogether by using
    modinfo in kernelcfg).


    That's all. I think my ideas can make modules even more usable than they
    are now; I expect comments...


    . __ | Phone: 03-5340753 (home), 03-9685882 (work)
    _| / | email:
    / | /_ 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.024 / U:0.764 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site