[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Thu, 15 Mar 2007 17:55:33 +0000 "Robin Cornelius" <robin.cornelius@xxxxxxxxx> wrote: > It does appear that more wireless drivers are requiring firmware to be > loaded every time (not kept in non volatile space on the card) so this > means more binary blobs. This is exactly my problem with wireless and Debian on the iBook. > One issue is with people like the FCC who are **terrified** that some > one will modify a wireless driver and be able to use a different > frequency than allowed. Which is why some manufactures that are > assisting open source also have the closed binary blob firmware to be > loaded. I've heard differing views on that - some dismiss these fears as little more than a conspiracy theory. Are the cards really capable of interfering with military transmissions or is this another example of the mentality that has banned mobile phones in hospital wards, petrol forecourts, aircraft etc. and even banned Palms/music players at take-off or landing? (i.e. an extension of the hysteria over mobile phone masts.) > At one point ralink with the rt2400 and rt2500 devices used (almost) > totally host software driven cards with very little processing done by > the device, but even here we had RF and BBP chips that required a > series of register programmings that did things like clock rates and > frequencies but we had no idea of what the numbers we were uploading > did. > > I am less apposed to having binary blobs that are loaded to an > external device to do something that binary blob drivers on my PC, > that's totally different but it would of cause be better if you could > have all the code. Agreed - the problem with binary firmware is principally to do with the kernel space. If the closed firmware in question gets loaded into the kernel address space (i.e. it is part of the driver) then this is a LARGE problem because the kernel team cannot help you when the driver trounces all over kernel memory addresses. If the closed firmware goes the other direction, from the filesystem (as a non-executable data file) to the device where it runs within the device with internal addressing, that is less likely to affect stability. So 3D accelerators that use binary firmware are BAD, wireless devices that rely on binary firmware to be loaded into the device at runtime are less bad. > Issues with this are that there are probably no > free compilers available for a given system as we are often talking > micro controllers and below rather than microprocessors. Given the source code, I'm sure the compiler can be patched. The portability of GNU/Linux microprocessor code has a lot to do with the flexibility of gcc. If any compiler can work with microcontrollers, I'd expect it to be gcc. As ever with closed binaries, everything is possible once the source code is free. There don't appear to be that many versions of binary firmware (contrary to what I expected) - the same files get used over and over. That has to be good for creating a free version. If someone could just figure out how to turn binaries into source code as easily as source code is turned into binaries, proprietary code would disappear overnight. Dream on.... -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpCOuFEYMzCN.pgp
Description: PGP signature
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html