[PATCH] Compile problem with WE 14

[Jean Tourrilhes]

On Tue, Dec 10, 2002 at 02:29:35AM -0500, Pavel Roskin wrote:
> 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.

	This number is unused in WE-14 and earlier and therefore safe
to use. The only thing is that the tools will drop it.
	If you want, I could use the same construct in the tools so
that IWEVCUSTOM would get supported also on WE-14. Actually, that's
probably a good idea, so I'll do it ;-)

> 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.

	Exactly. I tend to always add numbers and not remove them. For
example, APLIST is supposed to be deprecated, but I've decided that
after all I'll keep it.

> 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.

	Well, actually wireless.h is versioned *and* backward
compatible. The only two time I've remove stuff was v8->v9 and the
SIOCSIWCOMMIT accident, but I've learned my lesson.

> > 	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.

	A better example would have been the USB driver API. This one
has been a wild ride.

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

	Thanks for the advices, I'll try to be even more careful on
those point and write those rules in stone. That's another reason why
I won't remove APLIST support.

> Regards,
> Pavel Roskin

	Have fun...

	Jean