-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/6/12 5:12 AM, Jan Beulich wrote:
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).
Actually, there is. In the RPM build process, things that are added during 'make oldconfig' cause the build to fail. So all options need to be made explicit.
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.
I don't remember a time when that was the case, but if it switches, then we can evaluate it then. This is actually the first step of making the configs smaller and the next steps rely on this behavior even more. If that changes, then I write up a tool to integrate them. For now, "cat" is enough.
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.
Yeah, it would really have to be some hack to run_oldconfig.sh that notes changes to -xen and asks if the changes should apply to -ec2 or not. I think I'd rather go through an update cycle to gauge the actual effort required each time before putting work into doing that. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQmRAmAAoJEB57S2MheeWyXzEP/iRF4uCe6BL/C+XL/Qc85GiP MWJQFOK2EeGoOVFSSwgeAsO0KEAScDjctyDWLltz9ccT94bPqgkpKBoJwVpxmHB1 yvlmrLIbFs4VsS4UKwsmlRk1AidFaR0O3EhgdRLypg6uH5+MnyBKmJWHe2gQosiI wlzrv53VmOjcKWtu4CHOZktbzRv1FXGuFDP+xeop3MhGxVsgfXUYT+nb07j7u+N3 Kxvoehl/LvW6xEDz6nG5gE8GR5Hnm6LcBFpdAkLpwBW2KF3/s/rNCo4sK3JAdLWy 2qjFsWcC/nbQq3L1/SJz+uzoi4rhCWbztmKoXEp6PM38ic+ynYYMbeRS6kNLTSI5 5+76HrOQDYaMSeVEe5lN4UUJQB7NK9Eai8AlQOJznBcP6si2C5p1zX657lUvAL/a kj12Bam42j1535qCEpA1GnmJ6b4cRkJ8wbZNo0q7HEmqJBj8ixQF9AL/+aL/KJ1l 9BvBybgT9tcejY6M0H1v2zOwLAlrMO8mcLTdLOd4z7s0AaIKTTmq5CbSK18WwrSX IJ3yKQm/Rgvh4FOiynwl2jgjtsEvk0g2RsuemUIuT/SFWUPJMU0q0TUdv9smDmbx C9uOepzr5nqPQD9Om9gy7keUrQD0qsY0Q5SI0ean/9gFBOeC0wvyahi4ErgprNv4 d5EbJlp9JYdQTvUmSvTg =9F+A -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org