fun or real: proc interface for module handling?
Hello!
I was just joking around here, but what do you think about this idea:
A proc interface for module handling:
/proc/mods/ /proc/mods/<module-name>/<link-to-the-modules-use-us>
So we could try to load a module with
mkdir /proc/mods/ipv6
and remove it and every module which uses us with
rm -r /proc/mods/ipv6
Modul options could be passed my
echo "psmouse_noext=1" > /proc/mods/psmouse/options
which would also make it possible to change module options while running..
It's just an idea, perhaps someone likes this.. perhaps if there is enough feedback I even could think about implementing it.
Greetings'
Nico
ps: please CC, the majordomo isn't answering my subscribe requests..
Signature · 2 lines
echo God bless America | sed 's/.*\(A.*\)$/Why \1?/' pgp: new id: 0x8D0E27A4 | ftp.schottelius.org/pub/familiy/nico/pgp-key.new
Quoted 10 lines · Nico Schottelius
I was just joking around here, but what do you think about this idea:
A proc interface for module handling:
/proc/mods/ /proc/mods/<module-name>/<link-to-the-modules-use-us>So we could try to load a module with
mkdir/proc/mods/ipv6
and remove it and every module which uses us with
rm -r/proc/mods/ipv6
So far, so good.
Quoted 3 lines
Modul options could be passed my
echo "psmouse_noext=1" >/proc/mods/psmouse/options
which would also make it possible to change module options while running..
How would options be passed when loading? Some modules require that to load properly. Also, there are lots of options that can't be changed after loading. To enable this, I believe the whole option handling would need to be modified substantially. Instead of just storing the values in static variables, there would have to be some means of telling the module that its options changed. Then there's the task of hacking all modules to support this...
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 11 lines · M?ns Rullg?rd
Quoted 3 lines
Modul options could be passed my
echo "psmouse_noext=1" >/proc/mods/psmouse/options
which would also make it possible to change module options while running..How would options be passed when loading? Some modules require that to load properly. Also, there are lots of options that can't be changed after loading. To enable this, I believe the whole option handling would need to be modified substantially. Instead of just storing the values in static variables, there would have to be some means of telling the module that its options changed. Then there's the task of hacking all modules to support this...
Interesting :)
Maybe, it should cause no action to "mkdir /proc/mods/ipv6", nor echo "psmouse_noext=1" > /proc/mods/psmouse/options
_just_ "collecting" parameters by kernel, then eg creating a file /proc/mods/ipv6/load should cause to load the module. Of course there can be code to handle "on-the-fly" parameter change, but maybe this can be considered as optimal, and it should be not a must a module to support this
...
- Gábor (larta'H)
Quoted 19 lines · Måns Rullgård
Quoted 10 lines · Nico Schottelius
I was just joking around here, but what do you think about this idea:
A proc interface for module handling:
/proc/mods/ /proc/mods/<module-name>/<link-to-the-modules-use-us>So we could try to load a module with
mkdir/proc/mods/ipv6
and remove it and every module which uses us with
rm -r/proc/mods/ipv6So far, so good.
Quoted 3 lines
Modul options could be passed my
echo "psmouse_noext=1" >/proc/mods/psmouse/options
which would also make it possible to change module options while running..
Quoted 7 lines
How would options be passed when loading? Some modules require that to load properly. Also, there are lots of options that can't be changed after loading. To enable this, I believe the whole option handling would need to be modified substantially. Instead of just storing the values in static variables, there would have to be some means of telling the module that its options changed. Then there's the task of hacking all modules to support this...
How about
ln -s noext=1,speed=6 /proc/module/psmouse
to create it with options required on load.
Symlink is the only node creator that allows arbitrary content.
Otherwise, to be consistent with one value/file, it seem that instead of an options file you write to each option should have its own file. Options that can only be set during load would be readonly files.
Drifting slightly off-topic for this. Wouldn't it be less costly to have the configuration options be extended attributes of a file or directory instead of separate files in a directory? I've been wondering this for some time. I wouldn't want dynamic values, such as counters, to be extended attributes but values that never change could be. Extended attributes provide a nice NAME=VALUE implicitly in a consistent way without having to have all those inodes.
DISCLAIMER:
i don't use modules myself so the options in my examples are unlikely to be valid.
Signature · 5 lines
________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [email protected] Remember Cernan and Schmitt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Jul 31, 2003 at 02:34:01PM +0200, Måns Rullgård wrote:
| Nico Schottelius <[email protected]> writes: | > Modul options could be passed my | > echo "psmouse_noext=1" > /proc/mods/psmouse/options | > which would also make it possible to change module options while running.. | | How would options be passed when loading? Some modules require that | to load properly.
Possibility, why not just have a file, /proc/mods/initial, that you write the initial kernel module options to, e.g.
# echo "ne2000 io=0x300 irq=11" > /proc/mods/initial
Then you load the module using:
# mkdir /proc/mods/ne2000/
although you could skip this necessity and just load the module when someone writes to /proc/mods/initial.
Just a thought.
- --
+-------------------------------------------------------------+ | Stuart Longland stuartl at longlandclan.hopto.org | | Brisbane Mesh Node: 719 http://stuartl.cjb.net/ | | I haven't lost my mind - it's backed up on a tape somewhere | | Griffith Student No: Course: Bachelor/IT (Nathan) | +-------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/KgDhIGJk7gLSDPcRAngeAJ4mUbQGQaijQbelNW8/6nXkdT+P+wCfUJ3U I6J5l/5TS3UTrQlJb/D86YM=
=MIdk
-----END PGP SIGNATURE-----
Hi !
Quoted 4 lines · Nico Schottelius
Hello!
I was just joking around here, but what do you think about this idea:
Quoted 9 lines
A proc interface for module handling:
/proc/mods/ /proc/mods/<module-name>/<link-to-the-modules-use-us>So we could try to load a module with
mkdir/proc/mods/ipv6
and remove it and every module which uses us with
rm -r/proc/mods/ipv6
Well, this idea itsel is quite neat, and could sometimes save lots of time (esp. when dealing with serious modules' deps). I would like to propose slightly different appropach:
cp /lib/modules/2.6.0-test2/kernel/drivers/somedriver.ko /proc/modtree is equivalent to insmod somedriver.ko (or modprobe ?). (How one could pass module params in the former case ?).
Then, if no other module depends on it, then this entry (under /proc/modtree) is a file, otherwise its a directory, with all depending modules also either files or dirs. So, module removal would be as simple as
[ -f /proc/modtree/somedriver ] && rm /proc/modtree/somedriver || \
[ -d /proc/modtree/somedriver ] && rm -rf /proc/modtree/somedriver/* ; \
rm /proc/modtree/somedriver
Signature · 1 line
With all the best, yarick at relex dot ru.
Yaroslav Rastrigin [Thu, Jul 31, 2003 at 05:13:24PM +0400]:
Quoted 14 lines
Quoted 4 lines
Hello!
I was just joking around here, but what do you think about this idea:
Quoted 9 lines
A proc interface for module handling:
/proc/mods/ /proc/mods/<module-name>/<link-to-the-modules-use-us>So we could try to load a module with
mkdir/proc/mods/ipv6
and remove it and every module which uses us with
rm -r/proc/mods/ipv6
Quoted 5 lines
Well, this idea itsel is quite neat, and could sometimes save lots of time (esp. when dealing with serious modules' deps). I would like to propose slightly different appropach:
cp/lib/modules/2.6.0-test2/kernel/drivers/somedriver.ko/proc/modtree[...]
sounds nice, too.
With this idea the kernel would get the code directly, which is very nice.
Nico
Signature · 2 lines
echo God bless America | sed 's/.*\(A.*\)$/Why \1?/' pgp: new id: 0x8D0E27A4 | ftp.schottelius.org/pub/familiy/nico/pgp-key.new
Cool idea! Maybe for each module, it could have a subdirectory to it (like reiser4's files-as-directory (see http://www.namesys.com/v4/pseudo.html)) and in that subdirectory are files to configure the options. You take your module, module.ko, and you want to set some options (before or after loading it). Maybe you could do something like echo "true" > module.ko/option for your module. Then you just
cp module.ko /proc/modules or whatever directory to insert?