fun or real: proc interface for module handling?

fun or real: proc interface for module handling?

[Nico Schottelius]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: fun or real: proc interface for module handling?

[Måns Rullgård]

Nico Schottelius <nico-kernel@schottelius.org> 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
mru@users.sf.net

Re: fun or real: proc interface for module handling?

[Gábor Lénárt]

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)

Re: fun or real: proc interface for module handling?

[jw schultz]

On Thu, Jul 31, 2003 at 02:34:01PM +0200, Måns Rullgård wrote:
> Nico Schottelius <nico-kernel@schottelius.org> 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:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: fun or real: proc interface for module handling?

[Stuart Longland]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jul 31, 2003 at 02:34:01PM +0200, Måns Rullgård wrote:

| Nico Schottelius <nico-kernel@schottelius.org> 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-----

Re: fun or real: proc interface for module handling?

[Yaroslav Rastrigin]

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.

Re: fun or real: proc interface for module handling?

[Nico Schottelius]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: fun or real: proc interface for module handling?

[Grant Miner]

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?

Re: fun or real: proc interface for module handling?

[John Bradford]

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

RE: fun or real: proc interface for module handling?

[Downing, Thomas]

> -----Original Message-----
> From: Stuart Longland [mailto:stuartl@longlandclan.hopto.org]
> On Thu, Jul 31, 2003 at 02:34:01PM +0200, Måns Rullgård wrote:
> 
> | Nico Schottelius <nico-kernel@schottelius.org> 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