Re: Broadcom 43xx first results

[Kyle Moffett]

On Dec 05, 2005, at 15:42, Jiri Benc wrote:
> On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
> > This is __not__ "yet another stack". It is an _extension_.  It is  
> > all about management frames, which the in-kernel code does not  
> > manage.
>
> But this code should be part of the stack, as nearly every driver  
> needs it.

WRONG.  More than half the currently Linux-compatible wireless cards  
handle the wireless management packets in hardware, such that they're  
little more complicated than a basic ethernet device with a channel,  
an ESSID, and a list of MACs/APs.

> Management handling should be really managed by the kernel.

Yes, but it might not need to be in the base stack if it's largely  
functionally independent.

> The hard part is that every driver will need a slightly different  
> amount of this support depending on the amount of features that are  
> provided by firmware.

s/firmware/hardware/g.  This is _exactly_ why an external module  
makes a lot of sense.

> > We tried the code from the RTL driver, but it is total crap.  We  
> > dropped it again. We thought about using yet another out of kernel  
> > ieee80211 stack, but we began to write an extension to the in- 
> > kernel code. If that was right or wrong, well, that's the question.
> >
> > If you _really_ think we should have used $EXTERNAL_STACK, go and  
> > patch the driver to work with it.
>
> No. I just think we (everybody) should concentrate at one  
> particular stack, finish it and merge it. And I'm convinced Jouni's  
> stack is currently the best solution available - far far from  
> perfect, with many issues, but still the best - and it will finally  
> save as much time.

What you miss is that the kernel does _not_ go with the "rewrite it  
and replace it" methodology.  See Luben Toikov in the SAS flamewar  
for another example.  If a better stack exists, provide a nice clean  
set of totally functional changes that convert the current one into  
that one.  In the process, we even get to keep the nice parts of the  
current one that aren't in his (whatever they may be), and we always  
have a working wireless stack.  With the rewrite/replace solution,  
you end up broken or unstable half the time.

Cheers,
Kyle Moffett

--
Simple things should be simple and complex things should be possible
  -- Alan Kay



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/