That's all down to the vendor. There are vendors like NXP and Xilinx that are actually working on mainline trying to get all of their stuff in, ...
You're confusing the collaborative nature of the GPL with a decent interface. It's good that vendors are contributing, the colbaration is a good thing in general.
However, that is not the issue. You can have everything in tree and still have a well defined interface.
>stable for an amout of time that would make my life much much easier.
No it wouldn't.
Why wouldn't it? Hardware doesn't change that often, your argument seems to boil down to things change? If I have a driver for a network controller for example, why can't the underlying interfaces be kept stable or versioned? Why do I have to currently know what the kernel 'looks like', so long as I know interface version X is there, I'm good... so long as interface X is there in future then you can just load my driver... no fuss.
NetBSD and FreeBSD provide good example of how this can be done at the kernel level. Their binary interfaces, whilst still less exposed as a windows style fixed ABI are much cleaner and well defined. (So you can just generally use the same network driver on whichever machine you're running on as the underlying bus discovery and communication is handled at a lower layer, with a well defined and consistent interace).
As a driver writer you would like to have all of the new helpers and generic code that has been added to make writing drivers easier and reduces the duplication for hardware that does the same function with a slightly different hardware implementation.
As a driver writer I want a consistant interface so I don't have to rewrite the driver every time a new kernel is released. If I know I need to trivially re-engineer my driver every x years as that's the life of the ABI, that's fine. Doing it every few months becomes a less practical use of my time, especially if I'm being paid, which just compounds the problem of out of date software running when it shouldn't be.
For example: Would you want an ABI where you can present an block disk to the OS when you're writing an SD card host driver? No. Because that would mean you now have to rewrite the whole Linux MMC layer in your driver.
I don't see your point here... I would like an ABI that I could present a block structured storage at if I'm writing a driver for one, as these are quite common and I could write a driver to support a new one easly. If I'm implementing a new class of hardware then of course I need new interfaces. But your argument would seem to suggest that supporting a new hardware and having a decent driver interface isn't possible. Windows/macOS would suggest otherwise. So in your example, I'd have a stoarge class driver that implements the MMC layer, and exposes a well defined interface to the SD card host driver.
You could then not only be sure your drivers would work going forward, but you could swap out my MMC layer with your own if you so chose, as the interfaces would be well defined and remain consistant. This is just good software engineering, It really has absolutly nothing to do with open source or the GPL.
It's also a lot of work that noone want to do for free.
This goes back to my point of loading SATA drivers on Window XP, that had no concept of SATA. Can you not see how that is a good thing? Most USERS of Linux don't care about the GPL or 'upstream source' or vendors being good citizens, they just want their hardware to work, and be secure.
Like I said, it's hard.
What you actually want is for someone else that actually understands the SD card spec to have come along and carved out all of the pieces needed to write an MMC layer driver for an SD host so you can write a driver by filling in the 5 or 6 callbacks it needs to drive your specific hardware. Actually having to look after your code after that is the payment for having someone else make your life easy in the first place.
Yes. That's exactly what I want, but as well as that I want STABILITY... so those interfaces are well considered and extensable and either versioned or unchanging (lets be fair, versioned...)
(You do see that the 5 or 6 callbacks are a driver interface? JUST KEEP THEM STABLE).
A driver layer is exactly that, it's having someone else look after the bits I don't care about and not having them change all the time. This is why I say it's hard, it _does_ require a lot of work to make other peoples lives easier.
I can load a WDDM1.0 driver written for Windows Vista on Windows 10, I can't load a WDDM2.0 driver on Vista as it supports newer features that the Vista kernel doesn't know about.
Don't get me wrong, I understand your point of view (I think you conflate well designed code with open source, but hey), but unfortnatly it will be the death of Linux.
Google are writing a replacement OS for android, they're also working on a binary driver layer for Linux to SOLVE THIS EXACT PROBLEM. (I wouldn't be at all suprised if this is a Fuscia driver layer ported to Linux, that would be the smart thing to do from their point of view...)
And I can't be arsed to respond to the rest of what you wrote.
That's okay, I never asked you to. It's a forum on a tech news site, we're all just angrily shouting into the void really. No one cares what either of us think.
If vendors want their shit to work with mainline and LTS kernels coming off of mainline they need to work at getting their stuff upstreamed. It's simple as that. No one is going to waste time making their lives easier for the sake of it.
Just read that last sentance again. THAT is the problem. (Hint: Massivly reducing the workload of a lot of other developers isn't a waste of time).