Re: [Madwifi-devel] Re: hal.o x86_64

[Michael S. <mi...@sc...>]

On Thu, Feb 05, 2004 at 07:40:35PM -0500, Jason Childs wrote:

> that are software only based.  I personally think that this way of 
> building hardware is a joke anyway, and even if you were to make your 
> chipset use "firmware"
> you should have an embedded processor doing the work for you and not try 
> to tax your main processor time for it.  I mean come on open source 
> verilog IP cores are
> available if you company's bean counters are worried 
> (http://www.opencores.org).
> 
> Take for example, the prism GT chipset.
> 
> They use an arm processor built into the core of the chipset.  So there 
> is no dependency on object files that the user has to worry about. 
> Granted the object
> file needs to be loaded onto the chipset on boot, but the user can still 
> compile the open source driver code and get it to run on any platform. 

But on the other side, the user has to live with what the object file
provides. I have seen lots of cases where the card firmware was buggy or
lacking features, and the manufacturer was not interested. If for example
the manufacturer is only interested in selling the card as a client, you
will not get to build an AP using the provided firmware.

The way Atheros builds the chips, you get maximum flexibility: the driver
has full control of the hardware and can send/receive everything he wants,
and using the HAL approach, we are free to utilize that in the open driver.
As I see it, the HAL places a lot less restrictions on the driver than most
embedded-CPU--with-firmware based cards do.

> The bottom line is
> that creating drivers that need object files to compile is just wrong 
> for an open system.

I do not see the big difference when comparing this against drivers that
require closed-source firmware, possibly of the kind where you are not even
allowed to redistribute the firmware with your open-source driver.

cu
Michael