linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* fun or real: proc interface for module handling?
@ 2003-07-31 12:12 Nico Schottelius
  2003-07-31 12:34 ` Måns Rullgård
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Nico Schottelius @ 2003-07-31 12:12 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: scholz

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: fun or real: proc interface for module handling?
  2003-07-31 12:12 fun or real: proc interface for module handling? Nico Schottelius
@ 2003-07-31 12:34 ` Måns Rullgård
  2003-07-31 13:03   ` Gábor Lénárt
  2003-07-31 23:15   ` jw schultz
  2003-07-31 13:13 ` Yaroslav Rastrigin
  2003-07-31 23:59 ` Grant Miner
  2 siblings, 2 replies; 10+ messages in thread
From: Måns Rullgård @ 2003-07-31 12:34 UTC (permalink / raw)
  To: linux-kernel; +Cc: Nico Schottelius

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: fun or real: proc interface for module handling?
  2003-07-31 12:34 ` Måns Rullgård
@ 2003-07-31 13:03   ` Gábor Lénárt
  2003-07-31 23:15   ` jw schultz
  1 sibling, 0 replies; 10+ messages in thread
From: Gábor Lénárt @ 2003-07-31 13:03 UTC (permalink / raw)
  To: M?ns Rullg?rd; +Cc: linux-kernel

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)

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: fun or real: proc interface for module handling?
  2003-07-31 12:12 fun or real: proc interface for module handling? Nico Schottelius
  2003-07-31 12:34 ` Måns Rullgård
@ 2003-07-31 13:13 ` Yaroslav Rastrigin
  2003-07-31 13:29   ` Nico Schottelius
  2003-07-31 23:59 ` Grant Miner
  2 siblings, 1 reply; 10+ messages in thread
From: Yaroslav Rastrigin @ 2003-07-31 13:13 UTC (permalink / raw)
  To: Nico Schottelius; +Cc: linux-kernel

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: fun or real: proc interface for module handling?
  2003-07-31 13:13 ` Yaroslav Rastrigin
@ 2003-07-31 13:29   ` Nico Schottelius
  0 siblings, 0 replies; 10+ messages in thread
From: Nico Schottelius @ 2003-07-31 13:29 UTC (permalink / raw)
  To: Yaroslav Rastrigin; +Cc: Nico Schottelius, linux-kernel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: fun or real: proc interface for module handling?
  2003-07-31 12:34 ` Måns Rullgård
  2003-07-31 13:03   ` Gábor Lénárt
@ 2003-07-31 23:15   ` jw schultz
  2003-08-01  5:55     ` Stuart Longland
  1 sibling, 1 reply; 10+ messages in thread
From: jw schultz @ 2003-07-31 23:15 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: fun or real: proc interface for module handling?
  2003-07-31 12:12 fun or real: proc interface for module handling? Nico Schottelius
  2003-07-31 12:34 ` Måns Rullgård
  2003-07-31 13:13 ` Yaroslav Rastrigin
@ 2003-07-31 23:59 ` Grant Miner
  2 siblings, 0 replies; 10+ messages in thread
From: Grant Miner @ 2003-07-31 23:59 UTC (permalink / raw)
  To: Nico Schottelius, linux-kernel

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?


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: fun or real: proc interface for module handling?
  2003-07-31 23:15   ` jw schultz
@ 2003-08-01  5:55     ` Stuart Longland
  0 siblings, 0 replies; 10+ messages in thread
From: Stuart Longland @ 2003-08-01  5:55 UTC (permalink / raw)
  To: linux-kernel

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: fun or real: proc interface for module handling?
@ 2003-08-01 13:54 Downing, Thomas
  0 siblings, 0 replies; 10+ messages in thread
From: Downing, Thomas @ 2003-08-01 13:54 UTC (permalink / raw)
  To: 'Stuart Longland', linux-kernel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: fun or real: proc interface for module handling?
@ 2003-07-31 13:51 John Bradford
  0 siblings, 0 replies; 10+ messages in thread
From: John Bradford @ 2003-07-31 13:51 UTC (permalink / raw)
  To: linux-kernel, mru; +Cc: nico-kernel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2003-08-01 13:55 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-31 12:12 fun or real: proc interface for module handling? Nico Schottelius
2003-07-31 12:34 ` Måns Rullgård
2003-07-31 13:03   ` Gábor Lénárt
2003-07-31 23:15   ` jw schultz
2003-08-01  5:55     ` Stuart Longland
2003-07-31 13:13 ` Yaroslav Rastrigin
2003-07-31 13:29   ` Nico Schottelius
2003-07-31 23:59 ` Grant Miner
2003-07-31 13:51 John Bradford
2003-08-01 13:54 Downing, Thomas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).