surviving Prism chipset

[Jouni Malinen]

On Sat, Nov 22, 2003 at 12:32:26PM -0800, Bobby Sardana wrote:

> The harware access layer (HAL) is in binary form for Atheros chips. So 
> if you want to learn the chip internals, it's a closed source.

Well.. In case of Prism2/2.5/3 (or PrismGT for that matter), it's the
closed source firmware doing the same thing if the goal is indeed to
learn the chip internals.. In case of Atheros, it is this same
functional component that's closed. It just happens to be running in the
host CPU.

The main goal, at least for me, is not to learn all the chip internals;
it is to have open platform that allows full operations on the IEEE
802.11 "layer". I don't think this requires knowing how some PHY
registers are configured etc., but yes, certain amount of low-level
information from the chip is needed.

However, the problem here for me is that some parts of the closed source
code happens to be running on the host CPU and in kernel space. Thus, it
has full access to the kernel memory and can potentially corrupt
something. Not having source code for this makes it difficult to debug
this kind of issues. Another major issue is support for all
platforms/CPUs that Linux supports. If the binary component is not
available for the CPU that I'm using, the driver is not very helpful. I
see Linux as a very portable system and thus, even a very small binary
only object is unfortunate.

Moving some of the lower MAC operations to the host CPU sounds
reasonable hardware design choice and I certainly prefer the host system
interface in Atheros design to solutions like PrismGT where almost
everything is hidden or wrapped in the firmware. Unfortunately, running
something closed in the host CPU just does not happen to fit very well
with the way Linux works; both from the licensing (GPL) and portability
point of views.

Moving some functionality, like radio/PHY configuration, from the kernel
driver to user space program (but keeping it still closed source) and
then open sourcing the full kernel driver, could help with the licensing
side and would make it easier to debug kernel drivers. However, we would
still be left with some of the portability issues because the user space
program would need to be run. Making this with some kind of virtual
machine might solve some issues, but then again, the end result is
starting to become way too complex..

Hopefully, some day, one of the wireless LAN chipset vendors agrees
that it is in their best interest to provide full documentation and
support for fully open source driver.

-- 
Jouni Malinen                                            PGP id EFC895FA