Hi, I think this is very interesting and tells us that when we push limit of the freedom, we need to be careful about its consequences.
On Mon, Apr 26, 2004 at 09:18:02PM -0600, Jason Gunthorpe wrote: > On Mon, 26 Apr 2004, Stephen Frost wrote: > > > entirely opposed to it either. Especially if the firmware is just > > assembled assembly for a specific processor that could be disassembled. > > I'm not very familiar with firmware though, is virtually all firmware > > compiled C code or is alot of it assembly or what? > > It varies. > > Sometimes it is C code running in a bare bones environment, or it is > running on something like VxWorks. > > Sometimes it can be truely weird stuff like FPGA configuration data. This > is becoming more common as people are just embedding mini-FPGA like blocks > in their ASIC's. Yes. As for "FPGA configuration data", I am sure the source circuit design data is compiled by the vender tools and/or proprietary tools so even if source is provided, the data is "non-free" or "contrib" according to DSFG. > Sometimes it is assembly code assembled using an assembler the vendor > built just for the logic they designed. > > Sometimes it is something else entirely - ie the intel microcode > patches. > > Pretty much everything has embedded 'firmware' of one kind or anyother. > Sometimes you don't see it, because it is in flash or ROM'd into the chip. > Though, often it ends up in a driver primarily to save on the cost of > flash and/or to ease updating it to new versions. > > The ocurrance of this is only going to increase with time.. So just delaying the introduction of new SC is not sufficient. We need to go back to old one despite it sounds unattractive. (Craig's proposal is the only good one in this respect.) In historic sense, when the SC was drawn, these firmwares were outside of "software" which we wanted to keep 100% free. So if we reactivate old one, we may not face this issue for good according to the "resolution" made in 1997. Osamu
