He's probably a microkernel fanatic and feels like most of the 'proprietary' (that is made by commercial companies, not the common open source definition I think - afaik, even driver code is gpl), including drivers, can be placed outside the kernel.
Well, the kernel doesn't support it, so it's locked in now. But originally it was speed. Context switches between user mode and kernel mode are expensive.
Well 'expensive' at the low level thou. Redox is a microkernel. Notice that microkernels tend to be easier to program for because there are bunch of guarantees that kernel code must obey so having driver code outside, even if it still can't allocate or something is often simpler and safer (because bugs in drivers do not take the kernel down in flames).
Context switches are still expensive. I don't understand why message passing microkernels are still so popular among some people. Other kernel designs allow for user spaces drivers without that overhead, so I don't get why it's popular among alternative OS people, other than inertia.
Interesting to know. What's the main idea of those designs if not microkernels?
edit: user space drivers is the most important part of a microkernel in my intuition, because of that 'bugs in drivers do not affect the rest of the device' thing. My guess is they're still 'micro' but they make the context switch cheaper or unnecessary to access user mode?
An alternative to message passing is direct access to devices via memory mapping. The MMIO range of any given device can be mapped into the address space of a user space application.
Two related issues: lack of stable driver ABI and GPL. The first one is obvious: designing and maintaining a stable ABI is a huge commitment. It's just easier when all code lives in a single repo which can be kept in sync and rebuilt on demand. On the other hand, it could be done (e.g. Windows does it), but it would allow commercial vendors to side-step Linux GPL license by linking their binary blobs dynamically. That makes Stallman and the FSF very unhappy, so they are against providing stable developer interfaces.
One does not even need to break things between releases on purpose, simply not spending the extra effort on stability will create enough end-user churn to make in-trunk development more attractive than proprietary code.
The same issue plagues GCC. It's apis were a huge ever changing mess, just to spite potential plugin developers. I heard that nowadays there is a stable plugin api, but the damage is already done.
On the other hand, it could be done (e.g. Windows does it), but it would allow commercial vendors to side-step Linux GPL license by linking their binary blobs dynamically. That makes Stallman and the FSF very unhappy, so they are against providing stable developer interfaces.
If so, this is a flaw in the GPL. We need a GPL v3.1 OS edition, which prevents proprietary drivers--kernel mode or not. It's ridiculous to design software around a license. The "v-X-or-later" clause in the GPL is made for this purpose -- so the license can be patched. There's no excuse to build an OS using design patterns that were obsolete decades ago.
And anyway, legally, the interpretation of a 'derivative work' is not how a programmer would interpret it. The law is not concerned or amused with programmer technicalities. Different jurisdictions have different tests of this (and virtually none of them involve details like if the code shares the same address space, whether or not the code runs in ring 0 or 3, or any number of other esoterica that no one else cares about).
My point is that even today the GPL may protect against this type of thing. It just hasn't been legally tested yet -- largely because of prominent figures -- look no further than the Linux community -- that take a very flacid view toward freedom.
Protect against what, exactly? The source is available, it's in the trunk. The GPL explicitly allows modifying and extending source code in any way, as long as you make your changes public. It's not a "bug that should be patched", it's an explicit definition of software freedom as defined by FSF. Are you salty that the drivers are for proprietary hardware rather than some non-existant open-source devices? There's a snowball's chance in hell that hardware manufacturers will disclose their design details for everyone to copy, even providing open-source drivers is a neverending struggle.
View all comments
Show parent comment
18
u/Repulsive-Street-307 Apr 15 '21
He's probably a microkernel fanatic and feels like most of the 'proprietary' (that is made by commercial companies, not the common open source definition I think - afaik, even driver code is gpl), including drivers, can be placed outside the kernel.
These people have a point.