Le 01/07/2017 à 22:09, Enrico Weigelt, metux IT consult a écrit :
> 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).
Precisely, the domain of embedded devices is one where HW vendors
write drivers. Motorolla/Emerson used to provide VME drivers for free,
but OOT despite the fact that the specs of the Tundra PCI-VME bridge
were public. They didn't do it for all releases.
> 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.
I learned that lesson. They provide proprietary drivers and Labview
for some versions of RedHat or Suze and only Labview knows how to talk
to them. The device was never used.
>
> Unless you wanna invest into proper reverse engineering, but then you're
> probably cheaper w/ creating your own HW.
Didier
::
Re: [DNG] kernel drivers [WAS: How …
