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..
--
echo God bless America | sed 's/.*\(A.*\)$/Why \1?/'
pgp: new id: 0x8D0E27A4 | ftp.schottelius.org/pub/familiy/nico/pgp-key.new
Nico Schottelius <[email protected]> writes:
> 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.
> 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...
--
M?ns Rullg?rd
[email protected]
On Thu, Jul 31, 2003 at 02:34:01PM +0200, M?ns Rullg?rd wrote:
> > 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)
Hi !
On Thursday 31 July 2003 16:12, Nico Schottelius wrote:
> 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
>
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
--
With all the best, yarick at relex dot ru.
Yaroslav Rastrigin [Thu, Jul 31, 2003 at 05:13:24PM +0400]:
> > 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
> >
>
> 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
--
echo God bless America | sed 's/.*\(A.*\)$/Why \1?/'
pgp: new id: 0x8D0E27A4 | ftp.schottelius.org/pub/familiy/nico/pgp-key.new
> > 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.
>
> > Modul options could be passed my
> > echo "psmouse_noext=3D1" > /proc/mods/psmouse/options
> > which would also make it possible to change module options while runn=
> ing..
>
> 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...
Or you could just cause the module to be unloaded and reloaded
whenever options changed.
Not that I like this idea anyway, but then I don't use modules :-).
John.
On Thu, Jul 31, 2003 at 02:34:01PM +0200, M?ns Rullg?rd wrote:
> Nico Schottelius <[email protected]> writes:
>
> > 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.
>
> > 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...
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.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
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?
-----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-----
> -----Original Message-----
> From: Stuart Longland [mailto:[email protected]]
> 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.
>From an newbie:
How about having a dir for each available module created earliest moment
in boot process, (point where depmod is done now I guess). Each dir has
files 'options' and 'load'. then you could:
# echo "io=0x300 irq=11" > /proc/mods/ne2000/options
followed by
# echo "1" > /proc/mods/ne2000/load
Of course, I am probably missing the point or something :-(
td