On Wed, Dec 03, 2003 at 10:33:19PM -0600, David Young wrote:
> Certainly it is a good thing if you only strive to connect your x86
> laptop to an AP using any old wireless card.
> * one of the goals of the NetBSD system is portability, and there
>   are not Win32 NDIS drivers for MIPS, Alpha, PowerPC, or Sparc (as
>   Martin mentioned)
	while it's certainly better to have a solution that works for more
than just x86 machines it sucks to obstruct the possiblity of getting
those x86 machines working with the hardware.

> * it is doubtful that most NDIS drivers will expose all the capabilities
>   of the chips, for example, the AP capabilities
	Not having all the capabilities you want is not a good argument for
preventing people from accessing the capabilities that are available.
If you really need all the capabilities for a particular card, then
you can (maybe) write a native driver for it.  Then again, maybe you
can't, either because the hardware vendor won't release docs, or because
you don't have the time to do it, or you'd just rather work on something
else.

> * I think that the NDIS drivers will duplicate (badly) the 802.11 state
>   machine, which means a buggy, bloated system
> 
> * the NDIS 802.11 API will probably not map to the BSD 802.11 API
	well, duh.  So the NDIS shim needs to map from one API to another.  Just
like the OS binary compat code needs to map from another OS's syscall API
to ours.  

> * I doubt the quality of vendor-supplied Win32 drivers, after reading
>   some crusty vendor-supplied driver sources
	mmm... yummy FUD and overgeneralization.

> * NetBSDers cannot fix bugs in closed-source Win32 drivers, and we
>   probably cannot get the vendor to fix all of them
	of course not, but we can't write all the drivers either.  We have
a limited amount of development resources.  There exist drivers for
hardware that people want to use.  We should certainly encourage native
drivers, and clearly explain that we can't, in any way, support or fix
problems with third party drivers.  However, it seems silly to completely
ignore those drivers when they can provide functionality that we would
otherwise not have at all.  The challenge it to strike a balance between
efforts to fixup netbsd to allow NDIS drivers to work and writing native
code.  The emphasis should be a on the latter, but not exclusively.

eric