no, the binary blobs that run in the kernel address space interact with kernel locking.
There are no blobs in kernel space if you run Linux using VMWare. It's all “on the outside”.
the R-pi drivers don't suffer any of these problems.
VMWare does not suffer from these problems either. It uses different techniques from r-pi (virtualization vs separate silicone) but the end result is the same.
complaining that they aren't 'real' drivers because they don't give you low enough access to the device is like complaining that your disk controller no longer gives you the ability to manually step the heads and you are limited to asking it to just give you a block.
Well, sure, I often use this example myself to show that gNewSense is somewhat hypocritical (it removes “unfree fimrware” from it's repository but can not really be used on a free systems without one: old 386/486 systems which had no binary blobs are not really powerful enough and all contemporary systems rely on non-free BIOS and non-free firmware in HDD, etc).
But there are big practical difference: HDD API changes are very slow and bugs are quite rare. With GPU it's direct opposite: bugs are frequent, and progress is rapid. That's why we really need GPU drivers and that's why we don't care all that much about HDD firmware.
or complaining that a modem only accepts AT commands, you can't use it as a sound card the way you can use a winmodem
Sure. I don't even remember when I've last used modem for the landline, but of course the fact that radiomodules are completely closed affairs on contemporary smartphones is a problem (and people tackle this problem, too).
no, most have blobs in kernelspace and/or userspace as well as in firmware, the r-pi eliminates the userspace/kernelspace binary blobs.
Which mobile chipsets are using kernel-level blobs? I think only nVidia does that and it's not all that popular. The rest are using userspace blobs and completely free shims in kernel - exactly like r-pi is doing except their blobs can be constrained (like any binary userspace program) while r-pi blob basically drives the whole circus.
The r-pi drivers could be used not only for X, but can be modified to work for Wayland, Mir, *BSD, or any other OS that wants to run on that hardware.
Binary drivers don't allow that.
Really? Have you heard about hybris project? It's can be used today to run Wayland, Mir, *BSD, or any other OS that wants to run on that hardware. Well, it can run Wayland and Mir at least, but I don't see what will prevent anyone from using it on *BSD.
It's not like they re-wrote everything to do this either, this is the architecture they created from the beginning, and why they warned people that getting the source for the kernel drivers wouldn't be very interesting.
Well, sure. They designed their chip to make sure they can separate it in two parts. Not uncommon design - only usually it's done to separate radiopart from main CPU, here it's done to separate GPU from CPU. It does mean we suddenly got open-source GSM drivers (in the form of list of AT commands) and it does not mean we suddenly got open-source GPU drivers for r-pi. Both are useful, both are closed source.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds