Hi,
being playing around with proc and sysctl for heaps of /proc/sys/ stuff,
and reading complaints about disain of related kernel common code,
I'd like to suggest, once more, something simple, extentsible and
object-oriented like that:
struct kernel_object_type_data {
struct kernel_object_inmemory_converters * memory_converters; //
convert to/from basic types and representations
struct kernel_object_backend_access * backend_access;
//functions,metadata related to data access, like device MIB read/write
struct kernel_object_frontend_access * frontend_access;
// to notify frontends about backends actions
};
struct kernel_object_metadata {
char * name;
struct kernel_object_permissions *permissions;
struct kernel_object_type_data * type; // inmemory
representation and access specific data and functions
atomic usage_counter;
};
struct kernel_object_directory {
struct kernel_object_metadata * metadata ; // common to all of same
type stuff
struct kernel_object_directory * parent; // like device in backend
and directory in /proc frontend
struct kernel_object_data * children ; // nullterminated
array, list, or smth.
struct kernel_object_frontends * frontend_data; // some list with
data set by different frontends
void * data; // like ptr
to struct net_device
someatomic usage_counter;// umm, lets
say -1 means: "under delete" ,0:free, >0: in use
};
struct kernel_object_data {
struct kernel_object_metadata * metadata ; // common to all of same
type stuff
void * data;
};
// or some other balance between data/metadata
this makes as minimum 8-16 bytes per data node,
which would allow more data to be exported.
This infrastructure would then start slowly to replace every kind
of terrible device,kerneldata<->kernel<->userspace
ways of interaction, which some like and some dislike
and so forth.
To find an agreement in those endless discussions, it
seems that the common part should be reduced to minimum.
Then everyone can read those data how they like.
proc,ioctl,sysctl,khttpd,xyzctl or whatever the way is.
Then simple people, like me, should not worry about
what is/willbe correct, mainstream and supported/developed.
elmer.
-
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 : Fri Apr 07 2000 - 21:00:15 EST