Re: Parser stable fix question for CFG80211_INTERNAL_REGDB

[Krishna Chaitanya <chaitanya.mgit@gmail.com>]

On Tue, Jul 1, 2014 at 8:11 PM, John W. Linville <linville@tuxdriver.com> wrote:
>
> 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@do-not-panic.com> 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...
>

Lot of embedded devices like ours avoid the pain of cross compiling
crda, udev...
and resort to internal_regdb as a easy way to get things done.


> 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?

Sounds good to me.