Indeed, for people who have never had to work with real hardware before, it is shocking how complex it is and the level of hackiness it sometimes takes to make it "work" (I say "work" because often times drivers are doing insanely hacky things to make it seem like it's working, even though it's duct tape and bubble gum under the hood). Not just when things are going right, but also when they go wrong (which can involve real-world physical things that break expectations, like damn voltage fluctuations or a physically damaged component for example!). When you only have "virtual" hardware to control, things are much, much, much more simple.
Yes, but that's way less work than maintaining an out-of-tree one is. Since fixes for kernel API changes are then the responsibility of whoever changed the API, instead of the driver's maintainer, it's basically the same amount of work it would be if the kernel did have a stable API.
That is not always possible due to licensing like OpenZFS's kernel module. There may also be trade secrets in a kernel module that they do not want to reveal by upstreaming. Upstreaming code takes time and it is not guarenteed that your patches will be accepted where an out of tree module can be created instantly.
It may not be needed, but in practice kernel modules will exist and make upgrading Linux harder than it needs to be. A stable API is about providing value and saving time for driver developers and end users. It is no coincidence that successful operating systems like Windows, Mac, and Android have stable ABIs that you can use to make drivers.
> A stable API is about providing value and saving time for driver developers and end users.
At the expense of undermining the quality of the rest of the kernel and burning kernel dev time.
> It is no coincidence that successful operating systems like Windows, Mac, and Android have stable ABIs that you can use to make drivers.
It's also no coincidence that drivers for previous versions of NT/Darwin regularly break with new releases, leaving users stranded while the Linux versions stay maintained in-tree. (I suspect the same is true of Android but I'm not familiar enough to say for sure)
>At the expense of undermining the quality of the rest of the kernel and burning kernel dev time.
It shouldn't undermine quality and it could save dev time and make it more user friendly to write new drivers.
Yes, drivers break over time, but it is better if there is a clear expectation on how long things will be stable and what changes will be needed when you upgrade.
> That is not always possible due to licensing like OpenZFS's kernel module.
Aren't these sorts of hardware drivers generally written in-house by the company who makes the hardware? Can't they pick whatever license they want since they own the copyright?
> There may also be trade secrets in a kernel module that they do not want to reveal by upstreaming.
A company that asserts the existence of "trade secrets" in kernel modules deserves to have to do the extra work. All kernel modules should be open source.
>Aren't these sorts of hardware drivers generally written in-house by the company who makes the hardware? Can't they pick whatever license they want since they own the copyright?
I gave you an example of OpenZFS where this is not the case. The code in hardware drivers may not be owned entirely by the company. It could have even been done entirely by a third party which may not even still be in business. Even if they were willing to license there would be extra costs in making the code into a state that can be upstreamed. Even then it might just never be accepted.
>A company that asserts the existence of "trade secrets" in kernel modules deserves to have to do the extra work.
This is an unreasonable stance that hurts end users. If no one exists to maintain the kernel module end users will get stuck on old, insecure, kernel versions. Even if they get updated it prevents people from upgrading until there is a version all drivers support.
>All kernel modules should be open source.
That is your opinion. It is not true in practice meaning there is utility in having a stable ABI.
The real world is not as nice as you imagine. These things do happen. Sure it's in a businesses best interest to avoid things like this, but that doesn't mean it will never happen.
I don't imagine the world to be a nice place. I think we're coming from different philosophical view points.
Murder is going to happen, I would say we should try and prevent it, not just accept that it is going to happen. Yes, that attempt will never be 100% successful, but that isn't a reason not to try and prevent murders to start with.
Huh. I thought the title might have been a grammar mishap ("from scratch" is how I read it first), but apparently Scratch is a kids-oriented visual programming tool: https://scratch.mit.edu/
My first exposure to code was with Scratch, it's a really nice tool to let kids build games and little animations while learning principles like control flow, conditionals, etc.
It's really not very difficult to do this. RISC-V is deliberately quite a simple ISA. The Sail model for it is only a few thousand lines of code, and you don't need remotely that much to run Linux if you compile for a limited target ISA (no floating point, etc.).
Also gives "Linux From Scratch" a new meaning.