On Tue, Feb 7, 2017 at 3:10 PM, Paul Boddie paul@boddie.org.uk wrote:
Meanwhile, all the bravado about monolithic kernels being best and there being no tolerance for any performance decrease whatsoever (not even 15% or whatever the number was) seems absurd in this age of endless exploits and after-the- fact mitigations, with a lot of Linux deployments being done on top of microkernels/hypervisors now, anyway.
i reaally wish that linus torvalds wasn't such a fuckwit about microkernels (L4Ka) and device-driver projects such as OSKit.
the linux kernel *really* should be the linux kernel i.e. the source code that's *IN* the kernel/src subdirectory of what's in the linux source tree and presently incorporates millions of lines of *driver* source code.
if the device drivers were actually split into their *own* project, a different attitude would be had towards l4ka, oskit and projects like it. u-boot, which has to *constantly* steal code (maintaining it utterly separately) from the linux source tree, could just use oskit or an oskit-like derivative instead. the l4ka project could maintain a SMALL tree of source code instead of having to forward-port its patches year after year (for about a decade so far) because linus's attitude is summarised as "go fuck yourself" if anyone mentions "microkernels" on the linux kernel mailing list.
there would also stand a high probability that the core would remain stable, making it much easier to drop different device-driver flavours on top, and that research project for "real-time-non-shutdown-upgrading-of-drivers" would actually stand a chance of being incorporated mainline as a result.
instead we have efforts like devicetree which have completely failed in their goals of stopping device driver proliferation. with nobody stepping up to unequivocably state that a dtb file is a GUARANTEED fixed device configuration that will, in 25 years, be GUARANTEED to work with a future updated linux kernel source file, all that's happened is that the device driver proliferation problem has moved from c and h files to .dts and dtsi files.
the one upside of dtb files however is a patch (yet to be incorporated) which allows dynamic runtime patching of devicetree to switch in completely new hardware with utterly different specifications.
anyway.
'nuff.
and yes, we have the problem that the EOMA68-A20 has to be released with the sunxi 3.4 kernel because it's the only one that supports all the hardware out-of-the-box.
l.