Messages in this thread |  | | From | Keith Owens <> | Subject | Re: modules directory | Date | Thu, 07 Sep 2000 09:06:58 +1100 |
| |
On Wed, 6 Sep 2000 18:07:13 -0400 (EDT), "Richard B. Johnson" <root@chaos.analogic.com> wrote: >Ahaa! Aye... Does this imply that there will, in the future, be >other than '/kernel/drivers' as modules? Or is this (I fear) another >change that; "Doesn't have to be better, only different..."
/lib/modules/`uname -r`/ modules.dep modules.pcimap System.map .config Any other text files that are kernel specific
build symlink
kernel/ modules that came from the kernel source tree pcmcia/ modules from external pcmcia package xyz/ modules from third party xyz package, e.g. vmware
The old method of mixing multiple sources into fs/, drivers/ net/ etc. made it impossible to clean out old kernel modules automatically during make modules_install. A common class of problem was caused by old modules when somebody changed an option from a module to in kernel but did not clean out the old modules first. Not any more.
The old modules_install method relied on human definition of the mapping from source tree to fs/, net/, misc/ etc. Kernel developers got this wrong all the time, which is why half the modules incorrectly ended up in misc/. Even worse, you could have multiple copies of modules, on in say fs/, the other in misc/ and you never knew which one was being used. Not any more.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |