[lkml]   [1997]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: modutils, the next generation
On Jan 15, 13:30, Theodore Y. Ts'o wrote:
> Right now kernel modules are in well-defined places in the filesystem.
> (/lib/modules, etc.) So while I see your point, I'm not sure how much
> different it really makes in the actual practice.

Have you considered that there are kernel-modules besides the ones that
come together with the kernel?

Look at iBCS, for example. When you have compiled it, would it be obvious
to you immediately which of the files lying around there is the module
(before having installed it)? Of course, iBCS doesn't even use the current
.o-convention, probably because the module would get lost between all the
other object files.

Look at binary distributions of modules (while I don't like them, there
definitely are good reasons for them). Once they're installed in
/lib/modules, it's obvious that the object-files are modules, but how can I
see from a "tar tvzf" whether a package contains a kernel-module?

After all, even though most of the configuration files on your system are
probably plain ASCII-files, are they called *.txt? No? So the must be a
good reason for *.conf or *rc. I definitely see some similarities to
naming-conventions for modules here.


PS: Sorry for wasting our time on such a seemingly simple topic while there
are probably much more important things to fix. But the .o has bothered me
since the first modules came out.
/* Martin Buck E-Mail: */
/* Student of electrical engineering WWW: */
/* University of Ulm, Germany Snail-Mail: Paukengasse 2, 89077 Ulm, Germany */
#include <disclaimer.h> /* PGP Key available MIME-Mail welcome */

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