Abramo Bagnara wrote:
> IMHO this is cleaner and easily extensible.
> I think it solve all the problems noted but the type checking one.
>
> struct proc_entry {
> char *name;
> int level;
> uid_t owner;
> gid_t group;
> mode_t permission;
> int type;
> void (*func)(int action, void *data);
> void *data;
> };
>
Great, now still a small step futher to get
even more easy and friendly solution:
struct kobject_small {
struct kobject_metadata * metadata;
void * data;
}; // 4 times less
struct kobject_metadata {
atomic_t usage_count;
char * name;
struct kobject_permissions * permissions; // and ownership,
struct kobject_type * type; //
};
which would make it even more friendly:
instead of :
> static struct proc_entry entries[] __initdata = {
> { "test", 0, 0, 0, 0755, PROC_DIR, 0, 0 },
> { "bar", 1, 0, 0, 0755, PROC_DIR, 0, 0 },
> { "x", 2, 0, 0, 0644, PROC_INT, 0, &x },
> { "y", 2, 0, 0, 0644, PROC_INT, 0, &y },
> { "z", 2, 0, 0, 0644, PROC_INT, 0, &z },
> { "foo", 1, 0, 0, 0644, PROC_CUSTOM, foo_fun, &data}
> };
there would be dynamic at module setup:
test_container = kobject_lookup_or_new_container(root_container,
"test");
bar_container = kobject_lookup_or_new_container(test_container,
"bar");
kobject_insert_array(bar_container, &x,
"x",&kobject_GenericRootWriteAllRead, &kobject_GenericInteger);
kobject_insert_array(bar_container, &y,
"x",&kobject_GenericRootWriteAllRead, &kobject_GenericInteger);
kobject_insert_array(bar_container, &z,
"x",&kobject_GenericRootWriteAllRead, &kobject_GenericInteger);
kobject_metadata_custom_type = kobject_lookup_or_new_typedata(
foo_size, foo_readfun, foo_writefun, foo_lockfun,
foo_unlockfun,
"Foo" , kobject_data_encoding_ascii, "This is the Foo
parameter of Some subsystem",
" if you change it, then SomeSubsytem takes a Foo action and
this is dangerous.");
kobject_insert_array(test_container, &data,
&kobject_GenericRootWriteAllRead, kobject_metadata_custom_type);
That would be same good, except
1. slower for module loading, but that is not important as this is
rare operation.
2. consuming much less memory if metadata containers are
resourcecounted-unique-representation
Also, there could be test_container registered at mydevice_driver.c
like that:
kobject_register_submodule(root_container,"test",
"mydevice_driver_kobjects.o")
// which would make that even more memory-friendly.
// if kobject-modules are auto(un)loaded
// if this pseudo-code becomes real sometimes in future.
Then this is so memory-friendly, that later:
struct kobject_permissions
could contain network permissions.
Which would make linux ready for a lot of applications
where memory is a issue.
Just a networked kernel with khttpd - that would be
largest linux marketplace then.
But it needs this _unification_ as
for real use routing tables, firewall rules, etc should
be manipulatable this (unified) way.
And no maintainer is going to do those changes in
their code if you just invent
just-another-proc-entry-way-of-being-lazy
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 : Sat Apr 15 2000 - 21:00:26 EST