Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
Raspberry Pi VideoCore driver code released
Posted Oct 25, 2012 7:58 UTC (Thu) by ebassi (subscriber, #54855)
Ah I just RTFA in full which says wayland should be possible.
I honestly cannot see how that would follow: the shim driver does not allow adding required extensions, in case they are not present and exposed already; and it doesn't allow fixing bugs — which I just know are there because all GLES and EGL implementations for Linux on embedded hardware suck beyond belief.
this is the same exact situation we already have with nVidia and their proprietary blob, or with the IMG open source Linux driver (which was used, amongst other platforms, on the Intel "Poulsbo" netbooks).
Posted Oct 25, 2012 8:10 UTC (Thu) by dlang (✭ supporter ✭, #313)
There is one difference that I see as being critical.
The binary blob doesn't run on the main CPU, and as a result, cannot affect or be effected by the rest of the code running on that CPU.
This means that changes in locking, changes in the kernel->driver API, and even changes in the X-> driver API (including making a Wayland or android driver) cannot be blocked because the vendor hasn't updated their driver for the new kernel yet.
It's much harder for bugs in the binary blob to break the kernel. locking problems in the binary blob cannot cause problems in the kernel, Other than DOS type problems, the only thing the binary blob can do to break the system is to start scribbling on memory that's not allocated to the CPU. this is still possible, but is a much, much smaller level of vunerability than when the binary blob is running in the same address space and on the same processor as the kernel.
I seem to remember a case a few years ago when Fedora didn't use the latest kernel that was out because NVIDIA hadn't updated their drivers to be compatible with it yet.
This sort of thing is not possible with everything that's running on the main CPU being open.
Posted Oct 25, 2012 8:20 UTC (Thu) by swetland (subscriber, #63414)
Obviously, a completely open driver where you can fiddle with any part of it beats the implementation running on an embedded core, but I'll take the embedded core any day of the week over having to have random proprietary binaries in userspace or (shudder) the kernel.
All I ask is that the architecture give the kernel a way to protect the apps processor and main memory from the dedicated cores. Debugging memory corruption issues originating from blackbox coprocessor firmware: very not fun.
Posted Oct 25, 2012 11:09 UTC (Thu) by endecotp (guest, #36428)
I hear that when this chip powers on, it's the GPU that starts first; it autonomously loads its firmware from flash, sets up the world, and then enables the ARM. It is Linux that is, in effect, running on the "secondary" processor.
Posted Oct 28, 2012 16:52 UTC (Sun) by JanC_ (guest, #34940)
As if you would have an open source Arduino program send graphics commands over the USB/serial interface to your Windows PC, let a closed source program on the PC render stuff on its screen based on those commands, and then claim the Arduino has an open source GPU driver.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds