Flemur wrote:Dunno if the bright idea for putting hundreds of drivers in one "kernel" comes from Unix...
Not really no. Linux is a modular kernel and the vast majority of drivers as well as other functionally discrete bits of code such as filesystem-types can and for distributions
will be modules. There's little functional downside to having lots of modules installed on the system; ones for functionality and/or hardware you do not in fact have are not loaded, just sit around your disk taking up a tiny bit of space. You can also of course always compile and install your own kernel, leaving fully out all you don't need.
But the fact that these drivers are supplied
with the kernel is an important characteristic of the open-source and specifically Linux development model. All Linux code is available to any interested programmer and closed drivers/modules are in this environment frowned upon: even one closed module means a system cannot ultimately be trusted since all kernel code, including modules, runs at the highest privilege and can do literally anything it wants. The FSF side of the Linux-scape would have this mean any such module would be banned outright; the engineering side is quite a bit less dogmatic but doesn't on the other hand compromise it's engineering principles to make allowances for closed code. Specifically, wants to be free to improve any part of the kernel at any time they see fit; will not provide for a stable binary interface for closed modules. With the level of churn in the Linux kernel this means that basically no non-trivial external module stands a chance of working unchanged with more than a few point-releases (and in reality it is worse; a single point-release with some specific set of options that also need to match between kernel and module is enforced.) With the (often) issues companies have with open code and (always) with frantically updating a driver to track today's kernel for years on end, the only workable model is having open drivers, integrated/maintained along with the kernel itself, where they will be changed right along-side the kernel-side interfaces they rely on, and by those changing those interfaces in the first place.
That is, more than "a bright idea" it's a near direct consequence of the open development model...
