Re: bcm4301: A mac80211 driver using V3 firmware

[Ehud Gavron <gavron@Wetwork.Net>]

[-- Attachment #1: Type: text/plain, Size: 3968 bytes --]

Not a developer, just a tester, and not a very good one... but I am a 
_USER_ so here's my take.

The USERs don't want to know what card they have or what driver they 
need or PCI IDs.  That's all stuff that makes them say "Linux Bad, 
*****s good." (Yeah I know, there's the whole driver moreass there and 
PCI VENs too) but anyway...

The driver should have a name that reflects its use and capabilities.

For example, bcm43xx is a reasonable name.  I don't like it personally 
because the google links to the site (berlios.de) that tell me that's 
why I need took a while to find but that's just semantics.

bcm43xx_mac80211 is a less reasonable name.  With respect to the coders 
who have put time into making this usable on by 4306 and almost usable 
on my 4311 I can say that I appreciate the effort... but the name needs 
work.

If I was king of driver package naming, the driver that works with v3 
and v4 firmware and supports crypto functions would be... 
broadcom80211bg or bcm80211g
The driver that only works with v3 (aka bcm43xx) broadcomv3
The driver that only works with v4 (aka bcm43xx_mac80211) broadcomv4

As time advances and bcb43xx_mac80211/broadcomv4 is brought to spec so 
it works great... its code would be integrated into 
broadcom80211g/bcm80211g.

That's my thinking.  As a USER.  As a linux advocate and zealot.

I can tell you there are three things that are the #1 hindrance to 
massive Linux adoption
1. proprietary video cards
2. proprietary network cards
3. the various sundry and astonishingly in-the-way and annoying 
network-managers.

If you can solve #2... you've eliminated 33% of the problem and maybe 
even helped with #3.

Go Lewis Hamilton @ Nurbugring
Go Paul Tracy @ Edmonton

Ehud

Pavel Roskin wrote:
> On Fri, 2007-07-20 at 09:44 -0400, John W. Linville wrote:
>   
>> On Fri, Jul 20, 2007 at 12:43:16AM -0400, Pavel Roskin wrote:
>>     
>>> Actually, the common practice is that the new driver that doesn't
>>> supplant the old driver immediately and for the whole range of hardware
>>> gets a new name.  Think CONFIG_IDE vs CONFIG_ATA and eepro100 vs e100.
>>>       
>>  
>> Yes, this preserves stability for happy bcm43xx users.  Still taking
>> suggestions for the new name for bcm43xx-mac80211... :-)
>>     
>
> b43
> bcm43
> bcm4k3
> bcmwifi
> bcmwlan
> bcm80211
> brcm43xx
> broadcom
>
> I really like the minimalism of b43, which plays well with b44 and
> p54 :)
>
>   
>>> Also, we could introduce a kernel option to enable support for new
>>> devices in your driver.
>>>       
>>  
>> Yes, this is probably worthwhile for those wishing to avoid PCI ID
>> conflicts between the drivers.  I have also been speculating that
>> perhaps we need an option for a secondary PCI ID table, so that a
>> driver could support a large range of PCI IDs but then gracefully
>> bow-out if another driver had a certain ID in its primary table.
>> Does that make any sense?  It would seem to be applicable to a number
>> of drivers in the kernel.
>>     
>
> Yes, I used to hearing complains that orinoco steals IDs from hostap.
> Then it became popular to blacklist orinoco modules.  Quite a disgrace
> for the driver!  Having "weak" IDs for Prism based cards would have
> avoided it.
>
> But please realize that the problem goes far beyond PCI.  Perhaps you
> have heard of CONFIG_USB_LIBUSUAL, which selects the best driver for USB
> storage devices, either the slow but reliable ub, or the SCSI based
> usb-storage, which it too fast for some cheap sticks.
>
> It even has a parameter called "bias", which allows to control how
> conservative the algorithm should be.  That would be hard to emulate
> with "weak entries", but I hope that "bias" is an overkill.
>
>   
>> Yes, we should probably start using a default value for fwpostfix.
>> As dwmw2 suggested, it would also be nice to fall back to an empty
>> fwpostfix if the firmware is not found w/ the default extension.
>>     
>
> Yes, that sounds good.
>
>   

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3283 bytes --]