On 15-2-2017 11:41, Johannes Berg wrote: > On Wed, 2017-02-15 at 11:34 +0100, Arend Van Spriel wrote: >> On 15-2-2017 11:34, Arend Van Spriel wrote: >>> On 15-2-2017 10:48, Johannes Berg wrote: >>>> On Wed, 2017-02-15 at 10:36 +0100, Arend Van Spriel wrote: >>>>> >>>>>> I'm not really sure what to do - we don't really want to >>>>>> print a >>>>>> message on something that might have been received from the >>>>>> peer, I >>>>>> think? Though I suppose we should return 0 for the invalid >>>>>> combinations, indicating that they're not supported. >>>>> >>>>> Ah. This is all non-functional code yet, right? At least having >>>>> a >>>>> static non-inline function in ieee80211.h will give build >>>>> issues I >>>>> would think. >>>> >>>> No, I marked it __maybe_unused so it'll be fine. I didn't want to >>>> have >>>> it inlined if you use it multiple times in a single source file, >>>> but I >>>> didn't want to move it to somewhere else either ... >>> >>> Ah. Now I understand the trickery ;-) Was there really no >>> "somewhere >>> else" to move it, because honestly it is confusing and a bit >>> wasteful if >>> used multiple times in cfg80211 and/or drivers. >> >> Although exporting it also comes at a cost. > > Yeah, we could put it into cfg80211 and export it. I haven't really > looked how big it is, but it does seem big. > > The other thing is that the ieee80211.h file was pretty much standalone > definitions of the spec until now - if we move it to cfg80211, should > the function prototype really be declared in this file? Well. You can look at it as being close to the spec (and it is), but if it is a function for cfg80211-based drivers it should go in include/net/cfg80211.h, right? Not sure though who will be using it apart from mac80211. So I guess we can do with the trickery. Maybe clearly mark it with a comment in ieee80211.h. Regards, Arend
