Hi Brian, >>> Well, I guess we could just run the command and look for EOPNOTSUPP... >> >> this kind of API design and usage is bad. Try-and-error approach is just not >> sustainable. > > Sure. That "suggestion" was quite literally an afterthought. Not > really a proper suggestion. > >> Even while it is late to add a proper flag that indicates support, we need >> to do this to make nl80211 better for the future. > > I suppose. I'm not quite sure how I would make use of that properly > though, given the corpus of kernels out there where the flag doesn't > exist (but the feature does). Some other heurestic for determining > kernel recency? Compile-time flags for the relevant user space, such > that one builds it for "new kernel API (w/ flag)" vs. "old kernel API" > (with the latter not even trying to look for the flag)? > > Or I guess a more proactive approach: implement both a "supported" and > an "unsupported" flag, so user space can figure out a tristate: flag > not available (old kernel -- user space is left to guess) vs. command > supported flag vs. command not supported flag. > > That seems a bit awkward though.
I would not make it this complicated. Add the flag for future kernels and the move on with life. Trying to workaround older versions is something I would not bother with. It is always possible to backport the feature to older kernels. And if you have a distribution or an OEM that cares, then that is what is going to happen. Regards Marcel
