Walter Dnes posted on Mon, 04 Mar 2013 11:28:50 -0500 as excerpted: > On Sun, Mar 03, 2013 at 10:48:07PM -0500, Rick "Zero_Chaos" Farina wrote > >> I am sorry that this package has been such a headache for you, >> unfortunately binary drivers (especially) are often like that. Thanks >> for all your hard work keeping this usable. > > I'm not a C programmer, let alone a developer, so this may be a stupid > question, but here goes... has anyone ever tried doing a HAL (Hardware > Abstraction Layer) to present a reasonably stable interface to binary > video drivers? Think of it as a shim translating a "pseudo-API" into > "the real API" that the kernel exposes directly. Surely, we can do > better than VESA. Give drivers 2 options... > 1) direct kernel access like now 2) access via the HAL/shim
Actually, I believe that's pretty much what the nvidia driver (specifically, in contrast to some other binary kernel modules) does. They have their binary core which is common between supported platforms, and an open-source kernel shim[1] that is what people build when they "build" the nvidia kernel module. However, due to the kernel's specifically NOT declared stable kernel- space-API[2], the shim code must change with nearly every kernel to match the new kernel code. As might be expected from a proprietary upstream that refuses to open their code and thus must support it themselves, upstream nvidia often falls behind, sometimes quite some way behind, both the kernel and xorg. Thus this thread... Of course it's possible to implement a userspace driver that wouldn't have the same issues as it'd use the stable userspace API, but that's generally accepted to be far too high a performance cost for graphics drivers, regardless of the kernel involved (MS tried it too for stability reasons and gave up at the performance penalty they were taking). --- [1] The shim is licensed MIT or the like, such that the code can link to both the kernel and the binary-core-black-box. So far, it has been allowed by the kernel folks under certain conditions, including that it not ship /with/ the kernel (various distros have run into that issue trying to ship it on their distribution media), and that it not attempt to link to the exported-as-GPL kernel symbols, just the general exported symbols. But the nvidia driver is in somewhat better legal shape than many binary drivers because it /does/ use the same common core, which thus can be argued not to be a derivative of the kernel and thus not to fall under the copyright law which gives the GPL its legal teeth. Between that and the open-sourcing of the shim, as long as they stick to the general exported symbols and don't try to use the GPL-exported symbols, they should be fine. [2] Ever-changing kernel-space-API: This is in contrast to user-space, which they put a LOT of effort into keeping stable. Also see the stable- api-nonsense document another reply already linked. Among other things, this both allows faster development and encourages the open-sourcing and upstreaming of code, since then the person doing the API changes must take care of it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
