On Mon, Jun 30, 2014 at 12:19:08PM -0700, Luis R. Rodriguez wrote: > On Mon, Jun 30, 2014 at 11:55 AM, Luis R. Rodriguez > <mcgrof@xxxxxxxxxxxxxxxx> wrote: > > For the current kernel we > > could intake the patch below, and I can port the change to no use > > dfs_cac, that would enable older kernels to use new and older versions > > of the ASCII database file. > > Personally I actually rather avoid us accept a patch upstream for a > userspace change. The problem here is that we failed to realize the > impact of CFG80211_INTERNAL_REGDB at build time with a userspace tool, > in this case the db.txt file wireless-regdb provides and its format. > > If we wanted to avoid a stable patch we could require a match between > wireless-regdb input file used for a kernel when > CFG80211_INTERNAL_REGDB is used at build time. That would require > different ASCII files on wireless-regdb or having the users of > CFG80211_INTERNAL_REGDB do the conversion themselves. Upstream would > just follow the wireless-regdb latest format. This then would just > require upstream a Kconfig update to clarify the requirements. > > This seems like a rather lazy option but also one that would be rather > more fair and honest for upstream, we could deal with a proper fix by > reconsidering the implementation of CFG80211_INTERNAL_REGDB completely > for future kernels. I'm shocked that anyone actually uses CFG80211_INTERNAL_REGDB... Anyway, I don't see the big deal. We should keep CFG80211_INTERNAL_REGDB (whether implemented in awk or C) up-to-date with current kernels. Anyone wanting to use an old kernel with an updated wireless-regdb file is responsible for ensuring compatibility. If they can't do that, then they should seek support from a vendor. How is this any different from any other kernel support issue? John -- John W. Linville Someday the world will need a hero, and you linville@xxxxxxxxxxxxx might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
