> > 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