Re: compat-drivers wishlist

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2013-03-28 at 23:40 +0100, Hauke Mehrtens wrote:
> > Now we can "source Kconfig.kernel" into our local Kconfig tree, and the
> > "depends on USB" can magically work the right way. For the symbol walk
> > (syms program above) we'll have to include an empty file, but that's not
> > terribly difficult either.
> 
> We also have to change all the select SOME_KERNEL_OPTION into a depends
> SOME_KERNEL_OPTION, because the options of the used kernel can not be
> changed.

Huh, good point. I didn't think about that, and it probably doesn't even
exist? But yeah, I agree, we need to do this. It's not terribly
difficult though -- after we have a list of local symbols we can go
through and rewrite "select NONLOCAL" to "depends on NONLOCAL".

> compat should be changed in this way to not always backport any e.g. all
> USB stuff and depend on USB stuff if the USB subsystem was not
> activated. I think this should be modularized to have one *.ko for the
> USB stuff, one for the PCMCIA stuff and so on.
> Currently compat.ko depends on USB for some kernel versions.

I don't think compat backports USB/PCMCIA/...? I was under the
impression that it was necessary to be from the base kernel anyway, but
I don't really know. In theory I agree, anything that's backported in
compat needs to be included into the Kconfig somehow, particularly
things like this.

Actually, I guess we do have things like that now, just not USB/PCMCIA:

CONFIG_COMPAT_FIRMWARE_CLASS
CONFIG_COMPAT_NET_SCH_CODEL
CONFIG_COMPAT_NET_SCH_FQ_CODEL
CONFIG_COMPAT_KFIFO
CONFIG_COMPAT_CORDIC
CONFIG_COMPAT_CRC8

and something about CONFIG_GENERIC_ATOMIC64 on non-64 bit platforms.

This is interesting! It probably means we need to generate a Kconfig
file for the kernel versions as well, at build time:

config COMPAT_KERNEL_2_6_26
	def_bool y

Obviously then compat relies more on compat-drivers to actually build?
It could have its own Kconfig file, and probably best if the creation of
this Kconfig.compat file is done through a script there.

Anyway this is special. So we can treat it specially, and do something
like

config COMPAT_CORDIC
	bool
	default !CORDIC

which should work just fine since we imported the symbols from the base
kernel. We'll then get a CPTCFG_COMPAT_CORDIC symbol that we can use to
build (or not) the cordic code.

For something that depends on a specific kernel version it's just as
simple:

config COMPAT_FIRMWARE_CLASS
	tristate
	default m if COMPAT_KERNEL_2_6_33 && !COMPAT_RHEL_6_1

or so.

johannes