Mailing List Archive

Re: RFC: /proc/module namespace
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?
--
fox@dallas.net (Fuzzy Fox) || "Just about every computer on the market
sometimes known as David DeSimone || today runs Unix, except the Mac (and
http://www.dallas.net/~fox/ || nobody cares about it). -- Bill Joy '85
-
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/
Re: RFC: /proc/module namespace [ In reply to ]
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.
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/
Re: RFC: /proc/module namespace [ In reply to ]
On Thu, 2 Sep 1999, Jeff Garzik wrote:
> > 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.
His point still stands - you've made a semantic distinction that wasn't
there before. 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.
--
"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/
Re: RFC: /proc/module namespace [ In reply to ]
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.
____
david parsons \bi/ That way lies madness.
\/
-
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/
Re: RFC: /proc/module namespace [ In reply to ]
Oliver Xymoron wrote:
>
> On Thu, 2 Sep 1999, Jeff Garzik wrote:
>
> > > 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.
>
> His point still stands - you've made a semantic distinction that wasn't
> there before.
No, I haven't. A "module" can be static or dynamic; Linus agrees with
me: Look at include/linux/init.h: I can use module_init() and
module_exit() regardless of whether the module is built into the kernel
or not. My feature is the same: you can use /proc/module/...
regardless of whether your module is a built-in module.
> 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.
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/
Re: RFC: /proc/module namespace [ In reply to ]
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/
Re: RFC: /proc/module namespace [ In reply to ]
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/
Re: RFC: /proc/module namespace [ In reply to ]
On Thu, 2 Sep 1999, Jeff Garzik wrote:
> Oliver Xymoron wrote:
> >
> > On Thu, 2 Sep 1999, Jeff Garzik wrote:
> >
> > > > 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?
...
> you can use /proc/module/... regardless of whether your module is a
> built-in module.
...
> > 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.
I think what Jeff is saying is that the information goes in /proc/$MODULE,
where $MODULE is substituted with the name the driver registers; rather
than the literal "/proc/module" directory with subdirs in it. If this is
the case, I think it's an elegant model. Some drivers are already doing
this by hand (eg. /proc/ftape).
If, however, the suggestion is to use /proc/module (sorry, I did not read
the patch yet), then I would agree with the posters; the name would be a
source of confusion ("why is it in /proc/module/floppy!? I built it into
the kernel!"). Perhaps /proc/driver/$NAME would be a better choice.
-bp
--
# bryan at terran dot org
# http://www.terran.org/~bryan
-
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/
Re: RFC: /proc/module namespace [ In reply to ]
Oliver Xymoron wrote:
> My point is that module != driver. A module is something that may be
> compiled separately from the kernel.
"may" is the key word. A driver can be compiled separately from the
kernel too, of course, making a driver and module the same thing.
The current kernel view of things is that EVERYTHING is a module. Most
kernel drivers behave exactly the same whether they are a module or not.
> So at the very least, the directory should be /proc/drivers. Except that
Since /proc/module naming is a source of confusion I'll buy that.
--
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/
Re: RFC: /proc/module namespace [ In reply to ]
"B. James Phillippe" wrote:
> If, however, the suggestion is to use /proc/module (sorry, I did not read
> the patch yet), then I would agree with the posters; the name would be a
> source of confusion ("why is it in /proc/module/floppy!? I built it into
> the kernel!"). Perhaps /proc/driver/$NAME would be a better choice.
Yes, it looks like /proc/driver/$NAME is a better choice than
/proc/module/$NAME.
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/
Re: RFC: /proc/module namespace [ In reply to ]
On Thu, 2 Sep 1999, Jeff Garzik wrote:
> Oliver Xymoron wrote:
> > My point is that module != driver. A module is something that may be
> > compiled separately from the kernel.
>
> "may" is the key word. A driver can be compiled separately from the
> kernel too, of course, making a driver and module the same thing.
No, you still misunderstand. A driver is a driver, a module is a module.
Some drivers happen to be modules and most modules happen to be drivers.
But they're _different concepts_. A driver can also be several modules or
a module can contain several drivers. Things can be modules that aren't
drivers - for instance, I once wrote a module that was a filesystem
image.
And I still maintain that simplified register functions are needed at the
top level of proc. It's a mess.
--
"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/
Re: RFC: /proc/module namespace [ In reply to ]
>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.
I'd quite like to see an __exit qualifier along the same lines as __init that
would cause functions so tagged to be thrown away in non-module builds. At
the moment you have to either accept memory wastage or surround your cleanup
code with #ifdef MODULE, as far as I can tell, which isn't especially pretty.
p.
-
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/
Re: RFC: /proc/module namespace [ In reply to ]
This is a multi-part message in MIME format.
--------------8424E419739CD10469B0B723
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
In response to feedback the patch has been updated. Now a
/proc/driver/$NAME directory is created upon request from the driver.
Note this is for driver-specific information that does not go elsewhere
in /proc.
This patch is against 2.3.16, and has been tested with my audio driver.
Jeff
--
Americans' greatest fear is that America will turn out to have been a
phenomenon, not a civilization.
-- Shirley Hazzard, "Transit of Venus"
--------------8424E419739CD10469B0B723
Content-Type: text/plain; charset=us-ascii;
name="patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="patch"
diff -urN /g/vanilla/v2.3.16/linux/include/linux/proc_fs.h linux/include/linux/proc_fs.h
--- /g/vanilla/v2.3.16/linux/include/linux/proc_fs.h Tue Aug 31 19:12:14 1999
+++ linux/include/linux/proc_fs.h Thu Sep 2 14:48:30 1999
@@ -54,7 +54,8 @@
PROC_SOUND,
PROC_MTRR, /* whether enabled or not */
PROC_FS,
- PROC_SYSVIPC
+ PROC_SYSVIPC,
+ PROC_DRIVER,
};

enum pid_directory_inos {
@@ -479,5 +480,40 @@
extern inline void proc_tty_unregister_driver(struct tty_driver *driver) {};


-#endif
+#endif /* CONFIG_PROC_FS */
+
+extern struct proc_dir_entry proc_root_driver;
+
+static inline
+struct proc_dir_entry *proc_driver_find (const char *module_name)
+{
+ struct proc_dir_entry *p;
+
+ p = proc_root_driver.subdir;
+ while (p != NULL) {
+ if (strcmp (p->name, module_name) == 0)
+ return p;
+
+ p = p->next;
+ }
+ return NULL;
+}
+
+static inline int proc_driver_unregister(const char *module_name)
+{
+ remove_proc_entry (module_name, &proc_root_driver);
+ return 0;
+}
+
+static inline int proc_driver_register(const char *module_name)
+{
+ struct proc_dir_entry *p;
+
+ p = create_proc_entry (module_name, S_IFDIR, &proc_root_driver);
+
+ return (p == NULL) ? -1 : 0;
+}
+
+
+
#endif /* _LINUX_PROC_FS_H */
diff -urN /g/vanilla/v2.3.16/linux/fs/proc/root.c linux/fs/proc/root.c
--- /g/vanilla/v2.3.16/linux/fs/proc/root.c Thu Aug 26 17:18:06 1999
+++ linux/fs/proc/root.c Thu Sep 2 14:48:30 1999
@@ -641,6 +641,14 @@
NULL,
NULL, NULL
};
+struct proc_dir_entry proc_root_driver = {
+ PROC_DRIVER, 6, "driver",
+ S_IFDIR | S_IRUGO | S_IXUGO, 2, 0, 0,
+ 0, &proc_dir_inode_operations,
+ NULL, NULL,
+ NULL,
+ NULL, NULL
+};
static struct proc_dir_entry proc_root_dma = {
PROC_DMA, 3, "dma",
S_IFREG | S_IRUGO, 1, 0, 0,
@@ -738,6 +746,7 @@
#endif
proc_register(&proc_root, &proc_root_stat);
proc_register(&proc_root, &proc_root_devices);
+ proc_register(&proc_root, &proc_root_driver);
proc_register(&proc_root, &proc_root_partitions);
proc_register(&proc_root, &proc_root_interrupts);
proc_register(&proc_root, &proc_root_filesystems);
--------------8424E419739CD10469B0B723--
-
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/
Re: RFC: /proc/module namespace [ In reply to ]
Oliver Xymoron wrote:
> And I still maintain that simplified register functions are needed at the
> top level of proc. It's a mess.
create_proc_entry() and remove_proc_entry() should work for most
cases...
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/
Re: RFC: /proc/module namespace [ In reply to ]
----- Original Message -----
From: Oliver Xymoron <oxymoron@waste.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Linux Kernel List <linux-kernel@vger.rutgers.edu>
Sent: Thursday, September 02, 1999 2:39 PM
Subject: Re: RFC: /proc/module namespace
> And I still maintain that simplified register functions are needed at the
> top level of proc. It's a mess.
I think I would like to see the names right under /proc, but I wonder if
/proc/drivers isn't a better choice just to avoid name collisions. Or
aren't name collisions really a big issue?
Regards,
Brad
-
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/
Re: RFC: /proc/module namespace [ In reply to ]
"Bradley D. LaRonde" wrote:
> I think I would like to see the names right under /proc, but I wonder if
> /proc/drivers isn't a better choice just to avoid name collisions. Or
> aren't name collisions really a big issue?
Name collisions aren't a big issue, but certainly a consideration. A
big motivation for me is scalability... what happens when you load a
bunch of drivers, all of which dump straight into /proc root? You get a
huge ls listing. It's bad enough when you have tons of processes (and
tons of pid inodes) in /proc. I don't want drivers to start doing that
too.
IMHO driver-specific /proc entries should go under directory
/proc/driver/$DRIVER. If there exists a general /proc interface for a
specific capability, only then should it go elsewhere. That at least
encourages driver authors to consider a sane /proc namespace which
scales with independent decisions made by other driver authors.
Regards,
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/
Re: RFC: /proc/module namespace [ In reply to ]
Followup to: <37CEB6DA.7D32FDB@pobox.com>
By author: Jeff Garzik <jgarzik@pobox.com>
In newsgroup: linux.dev.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.
>
I think that's bad naming scheme at the very best... /proc/dev/... or
/proc/driver/... probably would be better.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
-
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/
Re: RFC: /proc/module namespace [ In reply to ]
--5UGlQXeG3ziZS81+
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
On Thu, Sep 02, 1999 at 11:01:28AM -0500, Oliver Xymoron wrote:
> > No change in behavior at all. A module can be compiled into the kernel.
>=20
> His point still stands - you've made a semantic distinction that wasn't
> there before. 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.
Why not rename /proc/modules to /proc/components to indicate, that it's the
components of your running kernel to be seen there, both compiled in and
insmoded drivers/modules/components/objects/whatever.
Regards,
--=20
Kurt Garloff <garloff@suse.de> Wuppertal, FRG
PGP2 key: See mail header, key servers Linux kernel development
SuSE GmbH, N=FCrnberg, FRG SCSI drivers: tmscsim(DC390), DC395
--5UGlQXeG3ziZS81+
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
iQCVAwUBN89/txaQN/7O/JIVAQE9MgP+IM2eoHrJou9iV+a+1HiVnP9jun+DGBre
rCpz0iqQ+qUS3uEa2agrfMTb3vdiPAC+fbUZoSXx8vWy2x11yexqbXft3KZTP1lj
o+kLRKD4IfhY1wqduFzt3lq1IOTexIeq7UUVjdiqxjPDiX9Nd6dkgcqylEE6h+hf
F+cn8dhvHBY=
=MJUT
-----END PGP SIGNATURE-----
--5UGlQXeG3ziZS81+--
-
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/