[PATCH] Compile problem with WE 14

[Pavel Roskin]

Hello, Jean!

> 	Thanks for the good work, as usual...
> 	Note that there is another way to fix this one :
> -----------------------------
> #ifndef IWEVCUSTOM
> #define IWEVCUSTOM	0x8C02		/* Driver specific ascii string */
> #endif

I considered this possibility but decided not to use the constant that is
not supported to be on the safe side and to be consistent with the
approach that I don't really like.

If it just a number that wasn't allocated in WE 14, then it's OK to use.  
If there is something in the WE code that needs to support this function,
then it's a very different situation.

If you allocate new numbers in the next version on Wireless Extensions,
it's unreasonable to forbid newer drivers to use those numbers and provide
compatibility includes.  It's somewhat like forbidding to port a driver to
2.2 kernel because the major number for that driver wasn't allocated in
2.2 series.

I believe it's only reasonable to limit functionality of the driver if
that functionality relies on the actual code in the kernel, not on
_conventions_ that were in effect when the kernel code was written, if
they are not used in the code.

> 	Well... I wish I could have got it right at the first iteration in
> 96, this would have simplified the situation drastically. Unfortunately,
> I'm only a common mortal.

Not so common actually :-)

> 	Remember that some of those feature I'm adding to Wireless
> Extension are stuff you guys are asking for. And I try to make sure that
> new feature that you don't need or don't like don't get in your way.

And by the way, backward compatibility is a very hard thing to do right
even without those pesky guys :-)

> 	There is a few options :
> 	1) Don't use W-Ext at all, and have your own set of tools strongly
> linked with the driver, like linux-wlan-ng, or use a /proc interface,
> like airo.c.

Not an option.  Poor WE support is the reason why I'm using linux-wlan-ng
only if I absolutely have to, namely on cards with tertiary firmware and
to use prism2dl for firmware upgrade.

> 	2) Assume only a baseline WE (like WE-9), and ignore all
> functionality added after that. Refer to #1 for additional config.

That would be a step back.  Standardization is a good thing.

> 	3) Assume the lastest WE, and generate a compilation error for
> earlier WE, point to my web pages for necessary WE patches.

It's acceptable, but inconvenient and not quite compatible with 6.

> 	4) #if WIRELESS_EXT of all the features needed, which is the
> current solution.

Acceptable, but see below.

> 	5) Mix 2/3/4 too make the conditional blocks less granular. For
> example, you could decide to use scanning only after WE-15 (and not on
> WE-14), or not use IWEVCUSTOM at all.

This doesn't benefit the users.  Dropping functionality to simplify code
is not justified except some very specific cases, e.g. support for very
old code.  Dropping scanning support with the stock 2.4.20 kernel would be
outrageous.

> 	6) Include driver in the kernel, and use whatever WE version is in
> that kernel.

Acceptable, but not necessary.

7) Split wireless.h into 2 headers.  The API part should be versioned.  
The constant part should not be versioned, but instead should be backward
compatible.  New constants could be added, but removal of the old
constants would not be allowed.

> 	I would quickly point out that most Linux APIs are using solution
> #6 and it's having drivers out of the kernel that make things difficult.
> Don't take my word for it, just check driver/modules/hostap_compat.h and
> pcmcia-cs-XXX/include/linux/netdevice.h for example.

Yes, there is some similarity.  But I think there is another thing that 
makes things difficult - it's the number of user-configurable parameters 
and complexity of the protocol.  mii-tool is simpler that iwconfig.

> 	But, if anybody has any brilliant idea, please tell me...

Maybe not brilliant, but hopefully not stupid to be completely ignored :-)

-- 
Regards,
Pavel Roskin