In <Pine.LNX.4.04.10004221548150.23096-100000@beaker> Ricky Beam (jfbeam@bluetopia.net) wrote:
> 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.]
The LESS configuration changes/upgrades/etc are needed when new kernel is
installed the better.
>> * 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.
Yeah ? Really ? Even if you'll miss few drivers that way (arcnet, for example) ?
No, thnx. Now, instead of scanning ONE directory with hundreds of files you
need to scan FEW directories with hundreds of files. In ideal world it'll
be advantage, in real world:
-- cut --
$ for i in `find /lib/modules/2.3.36 -type d` ; do
> echo -n $i ; ls $i/* | wc -l; done
/lib/modules/2.3.36 580
/lib/modules/2.3.36/block 16
/lib/modules/2.3.36/atm 8
/lib/modules/2.3.36/cdrom 12
/lib/modules/2.3.36/fs 54
/lib/modules/2.3.36/ipv4 2
/lib/modules/2.3.36/ipv6 1
/lib/modules/2.3.36/misc 255
/lib/modules/2.3.36/net 97
/lib/modules/2.3.36/pcmcia 38
/lib/modules/2.3.36/scsi 51
/lib/modules/2.3.36/usb 23
-- cut --
where 43% of all modules are in misc anyway ? Plus:
1. Sometimes it's VERY hard to guess which hardware is supported by which
driver (yellowfin.o is driver for Packet Engines G-NIC PCI Gigabit
Ethernet adapter; tmscsim.o supports Tekram DC-390(T) and so on).
2. It's not clear when you should find some drivers (why ide-scsi emulation
module is in .../scsi while ide-cd module is not in .../cdrom but in
.../block ?)
>> * 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.]
NO. KERNEL should clear the directory. This is just PLAIN WRONG to use
expensive manpower instead of cheap computerpower.
>>All things considered, the cons outweigh the pros.
> No they don't.
Of course they do. If something can be RELIABLE done automagically it SHOULD
BE done. Leave sysadmin to do work which CAN NOT be automated yet, do not
waste his time for mechanical work. This stupid tree in /lib/modules/`uname -r`
gives you MYTHICAL advantages and produces REAL problems.
-
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:22 EST