On Sat, 14 Jul 2012, Cyrill Gorcunov wrote:
On Sat, Jul 14, 2012 at 07:48:27PM +0200, Borislav Petkov wrote:On Sat, Jul 14, 2012 at 04:43:32PM +0400, Cyrill Gorcunov wrote:For example to enable "PCI driver for virtio devices" I need to go to Device Drivers -> Virtio drivers, while I think it would be great to have everything virt. related in Virtualization section.Actually, we need something more generic than that: everything X-related should be automatically selected when setting CONFIG_X. And X can be any subset of configuration options which belong to one feature, be it KVM, distro-specific stuff, or CPU-vendor specific stuff, or whatever. I can imagine, for example, that when a user wants to have an AMD-specific config, it automatically selects CPU_SUP_AMD, X86_MCE_AMD (for MCE), MICROCODE_AMD (microcode support), AGP_AMD64, EDAC_AMD64 and a bunch of other AMD-specific features.sure, no doubts, it would be great! (I must admit I never looked up into kconfig parser code so i don't know if this could be achieved easily).
think of this as a variation of the miniconfig problem.Instead of the miniconfig being one file that specifies everything you want, that you then use to generate a real .config file, you instead have one _or_ _more_ config files that get combined and then used to generate the real .config file.
Doing this as a set of miniconfig snippets instead of as menu options in the main kconfig has the advantage that once the real .config is created, it can then be edited freely, without worrying about things like SELINUX being enabled when you want to do development on a different LSM.
The distro config would be the first of these, but then you could have multiple hardware specific config files (a vmware config, a KVM config, one or more config files for the systems that you own, a USB config to enable a bunch of the various USB deices that you want to support, etc)
The distros may choose to produce several miniconfig files, one the minimum infrastructure features they need, and then additional files for the rest of their config. For example, I could see them having a set of files
1. Core 2. architecture 3. architecture specific drivers 4. architecture neutral drivers (USB devices and similar)starting off with the distro config, the people creating this are going to be very familiar with kconfig and could create these by hand, but going forward we are going to want to have some tools to help sysadmins to create these files. Not knowing kconfig, it may be as simple as taking the miniconfig snippets that you start with, creating a .config and then doing a diff of that .config with the one the admin created, using the result as the new miniconfig snippet.
David Lang