On Sat, 22 Apr 2000, Keith Owens wrote:
>Cons.
>
> * modprobe needs to be updated whenever a new /lib/modules/`uname -r`
> directory is added or third party code is installed.
Modprobe or it's configuration... this is the way software is supposed to
work: it does _exactly_ what you tell it to do. [devfs has the same "con"
and nobody seems to care.]
> * Users have to hunt through subdirectories for modules.
This is not a "con". There's no way to tell what is what is a directory
full of hundreds of files. Say you want to know what network drivers
were available as a module... 'ls .../net' is a much better idea.
> * New directories need changes to Makefile as well as sub Makefiles.
So? New drivers need changes to Makefile as well. Are you an idiot or
just damned lazy?
> * A user can recompile a kernel to switch code from module to
> builtin. If they do not change the value of `uname -r` and forget
> to erase the old /lib/modules/`uname -r` contents, they end up with
> obsolete modules. This leads to code that is built into the kernel
> but still exists as a module, if the old module is loaded it tends
> to crash the kernel.
This hasn't one damned thing to do with a flat namespace. If you don't
delete it, it's still going to be there... the presence or abscence of
sub-directories makes no difference. [This is in the realm of System
Administration. If you change the module configuration, you really
should clear the directory.]
>All things considered, the cons outweigh the pros.
No they don't.
--Ricky
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:21 EST