lkml.org 
[lkml]   [1998]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Module Ideas: Persistence, PnP, and more...
    On Thu, 3 Sep 1998, Alan Cox wrote:

    > > 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
    >
    > Ick. Put them in one block and add a module syscall function for it.
    > Poking in kmem is messy

    Well, yes, poking in kmem *is* messy.
    But putting all settings in one memory block, adding this block's address
    to struct module, changing all modules to conform, *AND* adding a syscall
    is (IMO) even messier.

    Another point: if we use a separate program than rmmod to read the
    settings, it may be able to access settings of compiled-in drivers using a
    ksyms-like interface.

    Hmm... maybe I'm starting to get converted to your idea. For one thing,
    it just dawned on me that it avoids a race condition inherent in my kmem
    idea (i.e., what to do if the settings change while they're being read).
    We'd still need a mechanism to convert the parameters to `name=value'
    pairs, though...

    > More ...
    >
    > insmod some-card ports=`isapnp-find IDENT`
    >
    > I dont think much magic is really needed for this. Its tools solvable
    >

    Yes, I also said it's solvable by tools.
    My idea was to create an index of ID <-> module, so we can use

    <get $IDENT from bus scan>
    module=`modprobe -q isapnp-id-$IDENT`
    allowed_irq=`modinfo -P irq $module`
    allowed_io=`modinfo -P io $module`
    allowed_mem=`modinfo -P mem $module`
    <allocate $IRQ, $IO, $MEM>
    modprobe -k isapnp-id-$IDENT irq=$IRQ io=$IO mem=$MEM

    Where modprobe -q just prints the path it will use for the specified
    module (omitting the prerequisites), and modinfo -P prints the definition
    of the specified parameter for the specified module in machine-parseable
    format (so we know, in this example, what IO ports, IRQs, and memory are
    allowed for this module---if any are needed at all.)

    The index consulted by modprobe -q is built from MODULE_SUPPORTED_DEVICE
    strings embedded in the modules (this is already supported in
    include/linux/modules.h, just not used by modutils).

    And the parameter name conventions, plus the extensions to parameter
    definition syntax, are what makes this scheme feasible.

    -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.048 / U:118.808 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site