* Alexandre Oliva <aoliva@xxxxxxxxxx> [20080330 07:41]: > On Mar 29, 2008, Bob Arendt <rda@xxxxxxxxxx> wrote: > > > This is firmware that gets loaded in routine tg3_load_tso_firmware(). > > It's firmware for a chip that you don't have a compiler for (if a compiler > > exists - there may be a different development model, say VHDL for a FPGA). > > The other hex cases in tg3.c also appear to be firmware mods. I'm glad this > > is supplied in hex - I'd hate to need working cross-compilers for every > > chip that has a firmware blob in order to build a kernel. > > This is completely missing the point. I think it is you that misses the point here. > There are several firmware files in the kernel that *do* accompany the > corresponding sources. This argument of inconvenience of needing > cross-compilers is a distraction. It's not a matter of inconvenience (unless you happen to have written all the required compilers and will release them shortly for the benefit of everyone) as much as being sensible. Requiring something of the order of 30 different cross-compilers to build a kernel is not sensible. It is frankly begging for something to break. Not to mention that I'd love to hear you explain how you'll solve the issue where the firmware is written in hex from the word go, there never were any sources. > This is not a matter of where the software runs, whether you have a > compiler for it, or whether it's executable code. This is not a > technical matter. This is a matter of respect for the 4 freedoms. > This is a moral, ethical and social issue. If the API to the chip is published and covered by the open sourcecode in the kernel driver, how it works inside (where the firmware you so strenuously object to is run) is beyond reason to ask for. By your argument, you can not use a mobile phone from, in princip, any manufacturer, as you don't have the full sources to their OS (delivered as a firmware upgrade that you can't modify). You can not use ordinary PC's, as they have BIOS and storage controller firmware delivered as binary blobs, for which you do not have the sources to modify them with. > The fact that those bits are executable code for some particular > machine is relevant only because once it's code then you most likely > need source code to be able to study it and adapt it such that it does > what you wish (freedom #1, from the Free Sotware Definition). And what else would you want a NIC chip to do other than do the network talking for you? Your argument in this instance does not make any sense to me. > But even if they're just "plain data", "register initialization", or > other forms of conveying instructions to a hardware component, if it's > not possible to understand what it means by looking at the numbers, at > surrounding code, because it's missing critical pieces of information > that are not widely available, then whoever put the bits in there > either (i) decided to deny you the information they had in order to > come up with the numbers, or (ii) someone else did this to them and > they're just passing on the restrictions. Either way, someone is > imposing restrictions on your understanding of the code, and this gets > in the way of your enjoyment of freedom #1. The internal workings of the NIC chip may well be under NDA. You want access to the sources for the microcode updates for all processors released as well I take it. I suspect you now will abstain from using computers completely until you have received those - right? > Even though you can modify the numbers as you wish, you still don't > have freedom #1, because you still can't adapt that part of the > software to suit your needs. Changing it for the sake of changing, > just because you have permission to, is not enough. It takes the > ability of understanding it to be able to change it such that it does > what you want. This is a bogus argument. The example is a NIC chip and it's firmware. You will not be able to modify the firmware to run Doom. Face it, some hardware is not 100% open. Don't like it? Don't use it then. Even if you had the source for this firmware, without the detailed documentation of the chip and the inner workings of the adapter - you're still left fumbling in the dark. If you really want it open, have a nice long chat with USPTO and get them to invalidate all patents on software, business methods and everything else that prevents people from revealing how the hardware works. Or even better, design your own chip and make it completely open. You get exactly what you want then and everyone benefits. > With undocumented sourceless sequences of numbers created by someone > who refuses to let you make sense out of them or to let you improve on > them, be they plain data or code, you're out of freedom, so it's not > Free Software. Oh, but you can improve on them. Use ethtool and poke the firmware directly. If it breaks, you get to keep all the pieces. :) /Anders -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
