On 07/01/17 14:43, Didier Kryn wrote:

> They preserve the external API but change all the rest.

Yes, that's the way we support zillions of different devices,
especially in the embedded world, w/ relatively small efforts
(OF was probably one of the most important steps) and still offer
good performance and stability.

The kernel internals aren't just made for anybody outside the kernel
community - we care a great deal of not breaking userland APIs.

> I tell that because,a decade ago, I tried to write driver modules
> but the internal kernel API was never in sync with the doc,
> while there was a new edition of the doc every year;

Yes, documentation is always a big problem for a moving target
(which kernel internal APIs are by definition).

> This might be a reason why hardware vendors don't provide drivers
> for Linux: big effort for a little market.

It's simply not the jobs of HW vendors to provide drivers (like in
the proprietary world), it's their job to give us the proper specs
(assuming they even have one :o) and collaborate w/ us to develop
drivers and get them mainline.

OOT-drivers are a niche for special inhouse cases or really huge
things that remain in beta phase for long time. Even that is mostly
obsoleted by git.

Proprietary drivers aren't supported at all. They shouldn't even
exist.

By the way: the problem also exists for vendors where whole product
lines are *based* on Linux, eg. in embedded world. Often their images
are built with the hot needle and not actually maintained once on
the market (I'm currently writing IIO drivers for such a case).

Special fun is w/ NI DAQ devices (especially the USB ones). They still
don't wanna tell us how to drive them, and only offer their crappy
kernel blobs. But the USB subsystem enforces gpl-only for quite a long
time now, so they cant legally support usb devices w/ their kernel
blobs anymore (BTW: i hope ioremap() becomes gpl-only in near future),
leaving their customers (w/ *expensive* products) in the desert.
They'll have to stick w/ ancient kernels to get it working.

Lesson learned: never ever buy NI.
Unless you wanna invest into proper reverse engineering, but then you're
probably cheaper w/ creating your own HW.


--mtx