Re: RFC: /proc/module namespace

Jeff Garzik (jgarzik@pobox.com)
Thu, 02 Sep 1999 13:41:46 -0400

david parsons wrote:
>
> In article <linux.kernel.37CE1204.D41D0511@pobox.com>,
> Jeff Garzik <jgarzik@pobox.com> wrote:
> >Fuzzy Fox wrote:
> >>
> >> Jeff Garzik <jgarzik@pobox.com> wrote:
> >> >
> >> > This new feature provides a /proc playground for modules. As it
> >> > stands now, any random driver or module that exports something to
> >> > /proc generally must create a file, or directory, in /proc root. Over
> >> > time that can get messy.
> >>
> >> Does that mean that, if a device driver is compiled as a module, its
> >> data gets placed in /proc/module, but if it is compiled statically into
> >> the kernel, that the information will go somewhere else?
> >
> >No change in behavior at all. A module can be compiled into the kernel.
>
> I don't think that's the problem.
>
> The problem is putting /proc information into /proc/modules; unless
> the driver ALWAYS puts information there, it means that applications
> that use /proc have to root around in multiple places to get that
> information out.

1) A driver should ALWAYS put its /proc information under the
/proc/module/... tree.

2) This does not change /proc/modules at all, and has nothing to do with
/proc/modules.

Perhaps my example, with init_module(), confused you into thinking it
worked only for dynamic modules.

These days, modern kernel modules function exactly the same, whether
they are static or dynamic modules. That's why module_init() and
module_exit() exist: to enable a single codebase to support modules,
without #ifdef MODULE all over the code.

Jeff

-- 
Americans' greatest fear is that America will turn out to have been a
phenomenon, not a civilization.
                -- Shirley Hazzard, "Transit of Venus"


-
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/