Re: An alternative way of populating /proc

[Elmer Joandi]

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.