Messages in this thread | | | Date | Thu, 2 Sep 1999 12:59:12 -0500 (CDT) | From | Oliver Xymoron <> | Subject | Re: 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/
| |