:: Re: [DNG] kernel drivers [WAS: How …
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Enrico Weigelt, metux IT consult
Fecha:  
A: dng
Asunto: Re: [DNG] kernel drivers [WAS: How long should I expect to wait for openrc to be ready in devuan ascii]
On 07/01/17 22:50, Didier Kryn wrote:

> Precisely, the domain of embedded devices is one where HW vendors
> write drivers.


Most of the time you don't wanna use them. Especially not proprietary
ones. Just look eg. at fsl's gpu drivers: totally insecure and harmful.
(back when I read their adreno kernel patches, I've literally spit out
my coffe - easily exploitable (eg. userland can overwrite kernel memory
in various ways), not even trivial bound checks, horriby complicated,
practically unreadable. Written by somebody who obviously had no idea
what he's doing (there were even pieces of win32 code in there!).

Yes, a few chip vendors have actually some kernel folks on their
payroll, but usually just for the very low level stuff.

Board/SOM vendors usually aren't much better (with a few exceptions).
Industrial computer vendors like NI tend to be even worse. NI doesn't
even have kernel drivers for their crio modules . everything's supposed
to be done w/ Labview.

BTW: did any embedded GPU vendor (except perhaps Intel) ever publish
full specs and proper (free and mainline'able) 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.


Why didn't the work with the community to get everything upstream ?

>> 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.


I would have demanded my money back.

BTW: several weeks ago, I had an interesting call w/ several NI folks
(PR, sales, engineering, etc) about the driver situation, especially
for cRIO (which one of my client planned to use). Short summary: they
just dont have any drivers for the cards all. It's Labview-only, and
it's deeply twisted between FPGA+cpu - IOW: there aren't even defined
interfaces. They claimed they understood the problem, but still nothing
usable happended here. IOW: the actual decision makers still didn't
understand.


--mtx