On Tue, 2018-10-09 at 21:41 +0200, Johannes Berg wrote: > On Tue, 2018-10-09 at 10:48 -0700, James Prestwood wrote: > > The current driver hard codes various features, ext features and > > supported > > interface types when a new radio is created. This patch adds > > several new > > hwsim attributes so user space can specify specific features the > > radio should > > have: > > > > - HWSIM_ATTR_FEATURE_SUPPORT > > Bit field of nl80211_feature_flags flags > > - HWSIM_ATTR_EXT_FEATURE_SUPPORT > > Variable length bit field where bits map to > > nl80211_ext_feature_index > > values. > > - HWSIM_ATTR_IFTYPE_SUPPORT > > Nested attribute of flags containing all supported interface > > types. > > Each flag attribute sets support for an interface type. > > This seems rather wrong, most (extended) features require the > driver/device to actually *do* something. > > Let's say you enable NL80211_EXT_FEATURE_TXQS - but then nothing > actually happens when you try to configure those. Or let's say you > enable NL80211_FEATURE_TX_POWER_INSERTION but then nothing actually > happens when sending the frame...
Ok, that makes sense. The intent here was to test logic for detecting and handling supported driver features/iftypes, rather than actually using the features. But I do understand it would be strange for anyone trying to enable a feature, to find that all it does it set a feature bit (although this is exactly what we want :)). Would it be acceptable (for now at least) if we just included the iftype piece? I can pull that out into a new patch if so. > > johannes
