About that kernel variables interface, my dreams from the time I wrote
something.
For example Aironet's card has (approximately)
1000 different configuration/statistics options
400 of them writable
500 of unique type (nonrepetitive)
300 of writable unique type
100 of them unique writable configuration options
It comes to the point that if we want to show them all on 8MB box,
we need to be smart. (i.e., my driver shows in /proc/sys,
but it is quite on edge with memory usage an dmost of it is wasted)
Currently there is ctl_table, which is still a bit bloat for such a work.
(i.e. not clt_table but proc interface of it probabaly)
Basically there are different data:
representation2user type data (like that we show it as string)
representation2system type data (like that it is bitfield in hw/softw read in device powerdown mode :) )
permission data (currently filesystem permissions)
naming data (name (&path) in /proc/sys tree)
addressing data ( pointer, index in mib, whatever)
So, for each card and kernel subsystem to have a possibility to export all
it would like to, there could be just in a OO way:
struct kernel_object {
struct kernel_object_type * type; // representation, permission & other near-metadata
struct kernel_object * parent; // i.e. that avoids extra1 & extra2 like things
struct kernel_object_name * name; // unicode ? :)
struct kernel_object_data * data; // or constant parameter or child kernel_object
};
UID = path+name
represented between representation and lookup layers in a parsed form
like pascal strings length+string,'/',length+string,'/',...
lookup would be by UID (traversing tree from start every time) or *parent
And there would be then the representing layers:
proc,
sysctl,
some new syscalls,
khttpd(umm, implement PUT ?),
persistentstorage
which would NOT have their representation-specific data in kernel_object
and preferably would not have it at all, everything on fly.
Other thing could be domains:
that I register a kernel_object_domain (subtree) and if someone steps into
that (from whatever representation backend), there will be module
autoload(and quick unload) for to handle those data.
The point is:
if someone is going to implement it, he needs to
either 1. think deep.
or 2. implement it OO way
there are enough of such registries in kernel now: proc,sysctl,modules,
symbols...
there is only one way to make one size fit all
without planning every last bit of it, and that would be the OO way.
elmer.
PS: user/kernelspace,ioctl/sysctl arguments: i dont care, as long as every
driver-writer can live without writing some additional repetitive
crap-code in the place where he should be declaring data arrays.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:21 EST