Messages in this thread |  | | Date | Thu, 16 Jan 97 11:01 MET | Subject | Re: modutils, the next generation | From | Martin Buck <> |
| |
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.
Martin
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: martin-2.buck@student.uni-ulm.de */ /* Student of electrical engineering WWW: http://www.uni-ulm.de/~s_mbuck1/ */ /* University of Ulm, Germany Snail-Mail: Paukengasse 2, 89077 Ulm, Germany */ #include <disclaimer.h> /* PGP Key available MIME-Mail welcome */
|  |