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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
