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

[jw schultz <jw@pegasys.ws>]

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