[PATCH] Compile problem with WE 14
jt at bougret.hpl.hp.com
Tue Dec 10 12:19:53 EST 2002
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.
> Pavel Roskin
More information about the HostAP