Hi Eugene, On Mon, Jan 14, 2013 at 9:01 PM, Eugene <wifi.mailing.list@xxxxxxxxx> wrote: > 2013/1/14 Kalle Valo <kvalo@xxxxxxxxxx>: >> Eugene <wifi.mailing.list@xxxxxxxxx> writes: >> >>> How to add custom configuration command for cfg80211 based driver. >>> >>> For WEXT was private IOCtls (iwpriv). >>> >>> What the recommended way for nl80211/cfg80211? >> >> Luckily private commands are now banned, it was such a mess. Now you add >> a new generic command to nl80211/cfg80211 so that all drivers can use >> it. The benefit is that the driver can be changed without any >> modifications to user space. > > That's really good benefit. > But as a disadvantage for that approach required changes for kernel, > which cannot be done real-time (insmod for example). How so? If you have some new mode or feature, you implement support for it in cfg80211 and (if needed) mac80211, tell userspace about it through nl80211, build a driver that indicates that it has support for this feature, then add or patch user-space utilities to make use of it. >> Only exceptions are NL80211_CMD_TESTMODE for low level factory/RF tests >> and debugfs for developer debugging purposes. >> > > Hmm... > That's good point for testing, but still unusable for production. debugfs is for exposing internal state which would be useful for debugging, e.g. register values, low level statistics, etc. > Why kernel do not support custom commands, like TESTMODE? The goal, as I understand it, is to work out a framework for how TESTMODE could be implemented in a unified manner across all the drivers for all hardware which supports it. I'm not sure that any real progress has been made. > The reason is to unify all drivers? Precisely. User space shouldn't have to do anything "special" for any particular driver. I should be able to swap from an Atheros card to an Intel card and, providing the Intel card supports the features I'm using, userspace should continue on without any significant configuration changes. > But what about new (or proprietary) features, use kernel patches only? New features should be written into the wireless stack as I described above. Proprietary features ... well that's a tricky one. Unless there's a real compelling reason to do so, they're most likely going to be ignored unless other chipsets implement compatible features and a unified interface for utilising them can be figured out. Exactly what features are you wanting to implement? Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
