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