joerg.twinklephone at gmx.de
Sat Feb 9 03:12:11 CET 2008
Am Sa 9. Februar 2008 schrieb Steven Kurylo:
> > I don't
> > want to know how 802.11b protocol is handled in the wlan-chip. I want to
> > have a powerfull bugfree API for the subsystem.
> In a Free software world, we do want to know.
Ok, agreed. But where ends SW and starts HW. Dedicated custom processor;
bootload-firmware; flashrom-fw; OTP-rom fw; mask programmed rom fw; FPGA;
even hardwired comparators and adders? The src is worth nothing for an alien
cpu command set, the whole fw src is nothing without register documentation.
Where to stop? FW of the DVD-writer with burn-receipes, of the HD with the
algos of the head-amp-DSP therein? This is valuable IP of the
DVD/HD-Manufacturer, they won't disclose. Power management of WiFI exactly
> For various reasons,
> one of which is because there is no "powerful bugfree API".
True. For every level API. No matter if that's driver API (to the "firmware")
or HW-API (description of registers and chip functions).
> be bugs and we (as in the Free software community) can fix them; I
> don't want to be at the mercy of some random company.
You *always* are, one way or the other. If the description of a register (e.g
timing) is faulty, you won't fix anything, neither the driver nor the chip
itself, unless you have the chip design data (masks etc). See actual
processor bug, would you like to have microcode documentation, so you can
decide whether or not, and how you may fix it with a microcode patch? You
have to learn how the CPU works internally (down to gate-level timing) to do
so. And this means open HW, what nearly never will happen.
I feel quite like you, but i don't think anyone may *force* hw-manufacturers
to do it our way. Instead they should offer more support and information. And
guarantee a clean API.
More information about the community