On 05.11.12 at 20:26, Jeff Mahoney
wrote: I've been working on making the kernel configs easier to work with from the developer side. Currently, we have 42 kernel flavors across 9 architectures. For the most part, the configs should be similar. At least within an architecture family, they should be very similar with only slight differences between them to differentiate the flavor. I have some scripts that I'm still working on that will ultimately "reduce" the configs so that they really only contain the differences between them. For now, I'm looking at getting rid of the -ec2 and -vanilla flavors as targets to be manually configured.
The following patch adds the concept of "meta" configs where you can specify that a config is based on another one. This is really only to be used for specific configs like -vanilla and -ec2. My long-term plan is to have config/common, config/$arch/common, and config/$arch/$flavor (and config/$arch/$flavor.meta), all combining to create a single config. It makes it obvious where the differences are between the configs which makes our release kernels more consistent.
As part of this patch, config/{x86_64,i386}/{vanilla,ec2} are removed. That part of patch application is left to the reader since it seemed to lower the signal/noise ratio to include them.
The gist is that "# meta:<flavor>" acts as a #include. We can't use cpp because all of the "# CONFIG_BLAHBLAH is not set" will break it. When 'make oldconfig' is run there is a bunch of noise but the output is correct. The -ec2 configs are identical to the current ones.
Very nice! And I'm impressed that you started out with the ones presumably most difficult to deal with. One minor thing is that quite a few of the ec2.meta overrides could really be dropped (there's no need to express anything there that is not [indirectly] user selected, e.g. !PCI implies !USB_ARCH_HAS_*HCI). The thing that puzzles me a little is that you add the overrides to the end of the base config: So far it was my understanding that the first setting wins, but this apparently changed at some point without me noticing. Question of course is whether you want this to be dependent upon upstream not changing the behavior again.
The vanilla ones aren't because they diverged from -default a bit. (I may sync them up before applying this, just to remove that bit of confusion).
The vanilla config will always be a one-off of the default or desktop flavor and so adding the few options to it is easy.
One obvious problem is how to deal with the fact that the -ec2 flavor essentially reflects a static set of hardware so that new drivers shouldn't be enabled in it -- but should be enabled in the -xen flavor. I'm open to suggestions on how to handle that easily. Right now it requires manual intervention.
I can't think of suitable alternatives, as individual settings don't identify themselves as controlling hardware support or software features. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org