lkml.org 
[lkml]   [1999]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC: /proc/module namespace
On Thu, 2 Sep 1999, Jeff Garzik wrote:

> > If it's not a module, then why is it listed in
> > /proc/modules? Maybe the top-level proc code needs to be cleaned up
> > instead.
>
> You're not making sense. This has nothing to do with anything listed in
> /proc/modules or the top-level proc code.
>
> Even if you cleaned up the proc code, module authors would still have no
> standard place to put extra, driver-specific /proc entries. My patch
> adds that.

My point is that module != driver. A module is something that may be
compiled separately from the kernel. A driver is (generally) code to
support a specific piece of hardware. While in practice they're often the
same, they are conceptually very different. And what it seems to me you're
trying to address is the maintenance of the proc code for new _drivers_
because it's the _driver's_ information we're interested in, regardless of
whether or not it's modular. Eventually everything may be modular or
modules may be replaced by something very different, but drivers will
remain. The current apparent relation between drivers and modules is
recent and not necessarily long lived.

So at the very least, the directory should be /proc/drivers. Except that
most everything in proc is conceptually a driver already, see? So what we
really need is a way for parts of the kernel to add stuff to the proc
hierarchy without touching the proc code. Ie register_procfile(pathname,
callback_that_takes_an_inode) and unregister_procfile(pathname).

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."


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

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.064 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site