Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 07:53:10PM +0200, Borislav Petkov wrote: > On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote: > > On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov wrote: > > > > > > Seriously, this helps only in the cases where the stuff the distro > > > actually needs is in modules. So, there probably are obscure situations > > > where you need to enable stuff which is bool and not M. > > > > Sadly, not obscure at all. > > > > Most of the *drivers* are modules, but most of the "distro config" > > options are indeed booleans (or, if tristate, =y). > > > > Even driver-wise, there are some things that are often =y, even though > > you generally don't want them. > > Tell me about it. I'm always pissed off when someone thinks his stuff is > very important and sets his sacred option to be =y/=m by default so the > wider audience can at least compile-test it while the majority of the > machines don't actually need it. > > A more coarse-grained config where most of the stuff is off by default > could take care of that probably. > > > PCMCIA? Not even *laptops* have that shit any more, but having > > built-in cardbus support almost certainly helps in a distro kernel for > > booting of certain odder cases. > > Yeah, distros need the one-size-fits-all thing so they have to enable > *everything*. > > > Xen support? Odd partition tables? All the different AGP versions? > > Many of us couldn't care less, but again, it makes sense in the actual > > distro kernel, even if it does *not* necessarily make sense in a > > personalized one. > > Yep. I proposed something that would solve some of this - but not during compile time but rather during boot-time [http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/99.html] (interestingly enough hpa was first to propose it 10 years ago :-) The goal is turn built-in components in well, unloadable components. That way you won't have at least that much stuff laying around not being used. Not the full silver bullet, but at least it gets some of this stuff out of the way and you don't have to worry about the extra stuff that was built-in. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 01:57:26PM -0400, Steven Rostedt wrote: > Yes, I know you know this already, as we discussed it in a pub over a > beer (choir practice). But this is a public forum on LKML (the church), > where I now have an audience of heathens. Convert! Convert! You are all > sinners! Ah, gotcha. [ … ] > But this still doesn't solve Linus's initial request. That would be a > single option that makes your distro boot, and work well. Again, that > option wont have the drivers needed, but it will enable all the core > infrastructure that you need. Oh I'm being additive here. You'll have feature profiles for the stuff we talk above and distro profiles which solve Linus' issue. Basically one coarse-grained config option will either select a feature which has a lot of small subfeatures of which some are sane and want to be enabled by default when selecting the topfeature. Or a distro-specific feature which could itself select other topfeatures. I haven't tried this in reality to actually be able to say that a tree-like configure approach would actually make sense and work. It sounds like a nice idea though, especially having the hierarchical structure. :) -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, 2012-07-19 at 19:34 +0200, Borislav Petkov wrote: > > I can pass the above to a allnoconfig, and the box will boot and allow > > ssh. Note, the reason for the serial config, is that this ktest run uses > > a serial port to see if the box booted. If the serial isn't there, then > > it thinks it failed. > > I agree with all this and you've explained this to me live already so > you're preaching to the choir. Yes, I know you know this already, as we discussed it in a pub over a beer (choir practice). But this is a public forum on LKML (the church), where I now have an audience of heathens. Convert! Convert! You are all sinners! > > But it would be a lot faster/easier if users can select, let's call'em > "profiles" which are not mutually exclusive and can speed up the > configuration process. They can either be distro-specific or generic, > selecting certain features you need. > > So configuring your kernel would be like shopping without paying too > much attention to details. Let's look into the head of a person doing a > config like that and read some of her thoughts :): > > "Hm, ok, this new configurator is cool, a lot faster I gotta say... So, > what do I need, ah, yes, it is an AMD laptop so from vendors I select > AMD, then I probably need ext4, then I'd like to do packet filtering > so I should enable iptables.. Oh, I'd like to do tracing too so let's > enable tracing and trust Steven with the options he's added by default, > then I need ahci, I'd also like to do encrypted partitions so I'll > enable device mapper with crypto... " > > So all those things could be selectable from that profiles menu without > having to go through the gazillion of little suboptions and having to > read help (which is sometimes completely helpless) and figure out do I > need it or not. > > And this would simplify configuration a lot. IMHO, anyway. > I totally agree with this. It would be nice to have a profile list where you can pick and chose what you have installed: network nfs ext3 serial xen kvm etc etc Where you can pick and choose what general features you want and it selects all the core infrastructure to get those features usable. It wouldn't select the device modules needed, you will still need to select what hardware you have. But it gets most of the work done for you. But this still doesn't solve Linus's initial request. That would be a single option that makes your distro boot, and work well. Again, that option wont have the drivers needed, but it will enable all the core infrastructure that you need. Going with my /usr/share/Linux/Kconfig, this could use the profile options as well. And just select those that are required. But then again, Linus did want a minimum selection of stuff. Side note (again), IIRC, "select" has a bug. If you have Config X selecting config Y but Y depends on Z, if you enable X, it will enable Y without enabling Z. I think there were some patches to address this, but I don't remember. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote: > On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov wrote: > > > > Seriously, this helps only in the cases where the stuff the distro > > actually needs is in modules. So, there probably are obscure situations > > where you need to enable stuff which is bool and not M. > > Sadly, not obscure at all. > > Most of the *drivers* are modules, but most of the "distro config" > options are indeed booleans (or, if tristate, =y). > > Even driver-wise, there are some things that are often =y, even though > you generally don't want them. Tell me about it. I'm always pissed off when someone thinks his stuff is very important and sets his sacred option to be =y/=m by default so the wider audience can at least compile-test it while the majority of the machines don't actually need it. A more coarse-grained config where most of the stuff is off by default could take care of that probably. > PCMCIA? Not even *laptops* have that shit any more, but having > built-in cardbus support almost certainly helps in a distro kernel for > booting of certain odder cases. Yeah, distros need the one-size-fits-all thing so they have to enable *everything*. > Xen support? Odd partition tables? All the different AGP versions? > Many of us couldn't care less, but again, it makes sense in the actual > distro kernel, even if it does *not* necessarily make sense in a > personalized one. Yep. > So doing "make allmodconfig" is certainly a workable thing (modulo the > modules that you need for stuff you hadn't happened to use), but it's > not wonderful. Oh and I always aim to build distro kernels on a big machine - allmodconfig build is no fun on a tiny laptop. So would it be better to have better profiled kernels, obviating the need for an almost full build? Hell yeah! > I also hate having to enable support for modules. A non-modular build > is quicker to build and avoids some security issues. Some drivers > don't work well built-in (they load firmware etc too early), but imho > it's worth doing if you can, and it's something we should make easy > for people to do because of the security side (of course, per-build > randomly generated keys and signed modules with the keys deleted after > the build would be reasonably equivalent from a security standpoint, > but we're not there yet). Agreed. So there are some not-so-obscure situations, judging by your examples above. Ho-humm. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 01:02:46PM -0400, Steven Rostedt wrote: > This is why I created the make-min-config in ktest. It keeps on > disabling configs to see what the machine needs to boot (and optionally > run some test), and what configs it can disable. It does not touch the > multi options though. > > It creates two configs. One that has the configs that it can't turn off > (still enabled with a make allnoconfig, or selected by something that it > must have), and a config that just has the configs that 'if I disable > this, the box doesn't boot'. > > Here's an example: > > For my min-config files with the configs that couldn't be turned off: > > $ wc -l config-min* > 117 config-min > 139 config-min-net > > The config-min will get the box to boot (no network). The -net, adds > enough to ssh to the box. > > $ wc -l config-skip* > 11 config-skip > 14 config-skip-net > > The above are the configs that ktest found if it disabled, would not > boot (or ssh). > > $ cat config-skip-net > CONFIG_SERIAL_8250_CONSOLE=y > CONFIG_SATA_AHCI=y > CONFIG_E1000=y > CONFIG_QUOTA=y > CONFIG_ATA=y > CONFIG_UNIX=y > CONFIG_INET=y > CONFIG_DEVTMPFS=y > CONFIG_EXT4_FS=y > CONFIG_DEVTMPFS_MOUNT=y > CONFIG_SERIAL_8250=y > CONFIG_BLK_DEV_SD=y > CONFIG_NET=y > CONFIG_NETDEVICES=y > > I can pass the above to a allnoconfig, and the box will boot and allow > ssh. Note, the reason for the serial config, is that this ktest run uses > a serial port to see if the box booted. If the serial isn't there, then > it thinks it failed. I agree with all this and you've explained this to me live already so you're preaching to the choir. But it would be a lot faster/easier if users can select, let's call'em "profiles" which are not mutually exclusive and can speed up the configuration process. They can either be distro-specific or generic, selecting certain features you need. So configuring your kernel would be like shopping without paying too much attention to details. Let's look into the head of a person doing a config like that and read some of her thoughts :): "Hm, ok, this new configurator is cool, a lot faster I gotta say... So, what do I need, ah, yes, it is an AMD laptop so from vendors I select AMD, then I probably need ext4, then I'd like to do packet filtering so I should enable iptables.. Oh, I'd like to do tracing too so let's enable tracing and trust Steven with the options he's added by default, then I need ahci, I'd also like to do encrypted partitions so I'll enable device mapper with crypto... " So all those things could be selectable from that profiles menu without having to go through the gazillion of little suboptions and having to read help (which is sometimes completely helpless) and figure out do I need it or not. And this would simplify configuration a lot. IMHO, anyway. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov wrote: > > Seriously, this helps only in the cases where the stuff the distro > actually needs is in modules. So, there probably are obscure situations > where you need to enable stuff which is bool and not M. Sadly, not obscure at all. Most of the *drivers* are modules, but most of the "distro config" options are indeed booleans (or, if tristate, =y). Even driver-wise, there are some things that are often =y, even though you generally don't want them. PCMCIA? Not even *laptops* have that shit any more, but having built-in cardbus support almost certainly helps in a distro kernel for booting of certain odder cases. Xen support? Odd partition tables? All the different AGP versions? Many of us couldn't care less, but again, it makes sense in the actual distro kernel, even if it does *not* necessarily make sense in a personalized one. So doing "make allmodconfig" is certainly a workable thing (modulo the modules that you need for stuff you hadn't happened to use), but it's not wonderful. I also hate having to enable support for modules. A non-modular build is quicker to build and avoids some security issues. Some drivers don't work well built-in (they load firmware etc too early), but imho it's worth doing if you can, and it's something we should make easy for people to do because of the security side (of course, per-build randomly generated keys and signed modules with the keys deleted after the build would be reasonably equivalent from a security standpoint, but we're not there yet). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, 2012-07-19 at 18:48 +0200, Borislav Petkov wrote: > > Also, if you are building on another box than what the kernel is for, > > you can go to that box and run 'lsmod > /tmp/lsmod'. Copy that file to > > the build machine (into /tmp/lsmod), and then run > > 'make LSMOD=/tmp/lsmod localmodconfig', and this will remove the modules > > not used by the target box. > > Seriously, this helps only in the cases where the stuff the distro > actually needs is in modules. So, there probably are obscure situations > where you need to enable stuff which is bool and not M. Hopefully those > cases are seldom enough so thanks for this, I'll try that the next time. > This is why I created the make-min-config in ktest. It keeps on disabling configs to see what the machine needs to boot (and optionally run some test), and what configs it can disable. It does not touch the multi options though. It creates two configs. One that has the configs that it can't turn off (still enabled with a make allnoconfig, or selected by something that it must have), and a config that just has the configs that 'if I disable this, the box doesn't boot'. Here's an example: For my min-config files with the configs that couldn't be turned off: $ wc -l config-min* 117 config-min 139 config-min-net The config-min will get the box to boot (no network). The -net, adds enough to ssh to the box. $ wc -l config-skip* 11 config-skip 14 config-skip-net The above are the configs that ktest found if it disabled, would not boot (or ssh). $ cat config-skip-net CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SATA_AHCI=y CONFIG_E1000=y CONFIG_QUOTA=y CONFIG_ATA=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_DEVTMPFS=y CONFIG_EXT4_FS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_SERIAL_8250=y CONFIG_BLK_DEV_SD=y CONFIG_NET=y CONFIG_NETDEVICES=y I can pass the above to a allnoconfig, and the box will boot and allow ssh. Note, the reason for the serial config, is that this ktest run uses a serial port to see if the box booted. If the serial isn't there, then it thinks it failed. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 10:42:17AM -0400, Steven Rostedt wrote: > On Sat, Jul 14, 2012 at 07:48:27PM +0200, Borislav Petkov wrote: > > > > Let's have an example: when I have to build upstream on a distro here, > > I take the distro config and use it despite that it takes a long time > > to build since everything is module - it is still better for me to > > wait that one time instead of doing a dozen of trial and errors after > > forgetting a config option each time. > > This is where 'make localmodconfig' does help. It can remove a lot of > modules for you. And I just recently fixed a bug in the tool that it now > removes even more modules (The fix is in linux-next). Even more modules? When is enough, enough? :-) > Also, if you are building on another box than what the kernel is for, > you can go to that box and run 'lsmod > /tmp/lsmod'. Copy that file to > the build machine (into /tmp/lsmod), and then run > 'make LSMOD=/tmp/lsmod localmodconfig', and this will remove the modules > not used by the target box. Seriously, this helps only in the cases where the stuff the distro actually needs is in modules. So, there probably are obscure situations where you need to enable stuff which is bool and not M. Hopefully those cases are seldom enough so thanks for this, I'll try that the next time. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On 17.7.2012 10:03, Geert Uytterhoeven wrote: > On Mon, Jul 16, 2012 at 10:56 PM, Linus Torvalds > wrote: >> On Mon, Jul 16, 2012 at 12:26 PM, wrote: >>> Some of the proposed ways to implement the minimum distro kernel would not >>> allow you to override the distro defaults because they would be implemented >>> by setting dependancies, not by selecting options that you as the user could >>> then unselect. >> >> The sanest thing to do is just a list of "select" statements. And in >> any case it would have to depend on the "distro config" entry, so EVEN >> THEN you could just create the Kconfig file, then edit out the distro >> config thing, and then do whatever you want. > > Except that "select" is one of the ugliest things in Kconfig, as it > blindly sets a symbol > without checking if its dependencies are fulfilled. But for the few options Linus proposed (TMPFS, TMPFS_POSIX_*, DEVTMPFS(_MOUNT)), the amount of additional dependencies is reasonable. For something more advanced like 'build me a kernel for a laptop with $VENDOR hardware', we would need a better dependency solver, indeed. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 07:48:27PM +0200, Borislav Petkov wrote: > > Let's have an example: when I have to build upstream on a distro here, > I take the distro config and use it despite that it takes a long time > to build since everything is module - it is still better for me to > wait that one time instead of doing a dozen of trial and errors after > forgetting a config option each time. This is where 'make localmodconfig' does help. It can remove a lot of modules for you. And I just recently fixed a bug in the tool that it now removes even more modules (The fix is in linux-next). Also, if you are building on another box than what the kernel is for, you can go to that box and run 'lsmod > /tmp/lsmod'. Copy that file to the build machine (into /tmp/lsmod), and then run 'make LSMOD=/tmp/lsmod localmodconfig', and this will remove the modules not used by the target box. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 07:48:27PM +0200, Borislav Petkov wrote: Let's have an example: when I have to build upstream on a distro here, I take the distro config and use it despite that it takes a long time to build since everything is module - it is still better for me to wait that one time instead of doing a dozen of trial and errors after forgetting a config option each time. This is where 'make localmodconfig' does help. It can remove a lot of modules for you. And I just recently fixed a bug in the tool that it now removes even more modules (The fix is in linux-next). Also, if you are building on another box than what the kernel is for, you can go to that box and run 'lsmod /tmp/lsmod'. Copy that file to the build machine (into /tmp/lsmod), and then run 'make LSMOD=/tmp/lsmod localmodconfig', and this will remove the modules not used by the target box. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On 17.7.2012 10:03, Geert Uytterhoeven wrote: On Mon, Jul 16, 2012 at 10:56 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Jul 16, 2012 at 12:26 PM, da...@lang.hm wrote: Some of the proposed ways to implement the minimum distro kernel would not allow you to override the distro defaults because they would be implemented by setting dependancies, not by selecting options that you as the user could then unselect. The sanest thing to do is just a list of select statements. And in any case it would have to depend on the distro config entry, so EVEN THEN you could just create the Kconfig file, then edit out the distro config thing, and then do whatever you want. Except that select is one of the ugliest things in Kconfig, as it blindly sets a symbol without checking if its dependencies are fulfilled. But for the few options Linus proposed (TMPFS, TMPFS_POSIX_*, DEVTMPFS(_MOUNT)), the amount of additional dependencies is reasonable. For something more advanced like 'build me a kernel for a laptop with $VENDOR hardware', we would need a better dependency solver, indeed. Michal -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 10:42:17AM -0400, Steven Rostedt wrote: On Sat, Jul 14, 2012 at 07:48:27PM +0200, Borislav Petkov wrote: Let's have an example: when I have to build upstream on a distro here, I take the distro config and use it despite that it takes a long time to build since everything is module - it is still better for me to wait that one time instead of doing a dozen of trial and errors after forgetting a config option each time. This is where 'make localmodconfig' does help. It can remove a lot of modules for you. And I just recently fixed a bug in the tool that it now removes even more modules (The fix is in linux-next). Even more modules? When is enough, enough? :-) Also, if you are building on another box than what the kernel is for, you can go to that box and run 'lsmod /tmp/lsmod'. Copy that file to the build machine (into /tmp/lsmod), and then run 'make LSMOD=/tmp/lsmod localmodconfig', and this will remove the modules not used by the target box. Seriously, this helps only in the cases where the stuff the distro actually needs is in modules. So, there probably are obscure situations where you need to enable stuff which is bool and not M. Hopefully those cases are seldom enough so thanks for this, I'll try that the next time. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, 2012-07-19 at 18:48 +0200, Borislav Petkov wrote: Also, if you are building on another box than what the kernel is for, you can go to that box and run 'lsmod /tmp/lsmod'. Copy that file to the build machine (into /tmp/lsmod), and then run 'make LSMOD=/tmp/lsmod localmodconfig', and this will remove the modules not used by the target box. Seriously, this helps only in the cases where the stuff the distro actually needs is in modules. So, there probably are obscure situations where you need to enable stuff which is bool and not M. Hopefully those cases are seldom enough so thanks for this, I'll try that the next time. This is why I created the make-min-config in ktest. It keeps on disabling configs to see what the machine needs to boot (and optionally run some test), and what configs it can disable. It does not touch the multi options though. It creates two configs. One that has the configs that it can't turn off (still enabled with a make allnoconfig, or selected by something that it must have), and a config that just has the configs that 'if I disable this, the box doesn't boot'. Here's an example: For my min-config files with the configs that couldn't be turned off: $ wc -l config-min* 117 config-min 139 config-min-net The config-min will get the box to boot (no network). The -net, adds enough to ssh to the box. $ wc -l config-skip* 11 config-skip 14 config-skip-net The above are the configs that ktest found if it disabled, would not boot (or ssh). $ cat config-skip-net CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SATA_AHCI=y CONFIG_E1000=y CONFIG_QUOTA=y CONFIG_ATA=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_DEVTMPFS=y CONFIG_EXT4_FS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_SERIAL_8250=y CONFIG_BLK_DEV_SD=y CONFIG_NET=y CONFIG_NETDEVICES=y I can pass the above to a allnoconfig, and the box will boot and allow ssh. Note, the reason for the serial config, is that this ktest run uses a serial port to see if the box booted. If the serial isn't there, then it thinks it failed. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov b...@amd64.org wrote: Seriously, this helps only in the cases where the stuff the distro actually needs is in modules. So, there probably are obscure situations where you need to enable stuff which is bool and not M. Sadly, not obscure at all. Most of the *drivers* are modules, but most of the distro config options are indeed booleans (or, if tristate, =y). Even driver-wise, there are some things that are often =y, even though you generally don't want them. PCMCIA? Not even *laptops* have that shit any more, but having built-in cardbus support almost certainly helps in a distro kernel for booting of certain odder cases. Xen support? Odd partition tables? All the different AGP versions? Many of us couldn't care less, but again, it makes sense in the actual distro kernel, even if it does *not* necessarily make sense in a personalized one. So doing make allmodconfig is certainly a workable thing (modulo the modules that you need for stuff you hadn't happened to use), but it's not wonderful. I also hate having to enable support for modules. A non-modular build is quicker to build and avoids some security issues. Some drivers don't work well built-in (they load firmware etc too early), but imho it's worth doing if you can, and it's something we should make easy for people to do because of the security side (of course, per-build randomly generated keys and signed modules with the keys deleted after the build would be reasonably equivalent from a security standpoint, but we're not there yet). Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 01:02:46PM -0400, Steven Rostedt wrote: This is why I created the make-min-config in ktest. It keeps on disabling configs to see what the machine needs to boot (and optionally run some test), and what configs it can disable. It does not touch the multi options though. It creates two configs. One that has the configs that it can't turn off (still enabled with a make allnoconfig, or selected by something that it must have), and a config that just has the configs that 'if I disable this, the box doesn't boot'. Here's an example: For my min-config files with the configs that couldn't be turned off: $ wc -l config-min* 117 config-min 139 config-min-net The config-min will get the box to boot (no network). The -net, adds enough to ssh to the box. $ wc -l config-skip* 11 config-skip 14 config-skip-net The above are the configs that ktest found if it disabled, would not boot (or ssh). $ cat config-skip-net CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SATA_AHCI=y CONFIG_E1000=y CONFIG_QUOTA=y CONFIG_ATA=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_DEVTMPFS=y CONFIG_EXT4_FS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_SERIAL_8250=y CONFIG_BLK_DEV_SD=y CONFIG_NET=y CONFIG_NETDEVICES=y I can pass the above to a allnoconfig, and the box will boot and allow ssh. Note, the reason for the serial config, is that this ktest run uses a serial port to see if the box booted. If the serial isn't there, then it thinks it failed. I agree with all this and you've explained this to me live already so you're preaching to the choir. But it would be a lot faster/easier if users can select, let's call'em profiles which are not mutually exclusive and can speed up the configuration process. They can either be distro-specific or generic, selecting certain features you need. So configuring your kernel would be like shopping without paying too much attention to details. Let's look into the head of a person doing a config like that and read some of her thoughts :): Hm, ok, this new configurator is cool, a lot faster I gotta say... So, what do I need, ah, yes, it is an AMD laptop so from vendors I select AMD, then I probably need ext4, then I'd like to do packet filtering so I should enable iptables.. Oh, I'd like to do tracing too so let's enable tracing and trust Steven with the options he's added by default, then I need ahci, I'd also like to do encrypted partitions so I'll enable device mapper with crypto... So all those things could be selectable from that profiles menu without having to go through the gazillion of little suboptions and having to read help (which is sometimes completely helpless) and figure out do I need it or not. And this would simplify configuration a lot. IMHO, anyway. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote: On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov b...@amd64.org wrote: Seriously, this helps only in the cases where the stuff the distro actually needs is in modules. So, there probably are obscure situations where you need to enable stuff which is bool and not M. Sadly, not obscure at all. Most of the *drivers* are modules, but most of the distro config options are indeed booleans (or, if tristate, =y). Even driver-wise, there are some things that are often =y, even though you generally don't want them. Tell me about it. I'm always pissed off when someone thinks his stuff is very important and sets his sacred option to be =y/=m by default so the wider audience can at least compile-test it while the majority of the machines don't actually need it. A more coarse-grained config where most of the stuff is off by default could take care of that probably. PCMCIA? Not even *laptops* have that shit any more, but having built-in cardbus support almost certainly helps in a distro kernel for booting of certain odder cases. Yeah, distros need the one-size-fits-all thing so they have to enable *everything*. Xen support? Odd partition tables? All the different AGP versions? Many of us couldn't care less, but again, it makes sense in the actual distro kernel, even if it does *not* necessarily make sense in a personalized one. Yep. So doing make allmodconfig is certainly a workable thing (modulo the modules that you need for stuff you hadn't happened to use), but it's not wonderful. Oh and I always aim to build distro kernels on a big machine - allmodconfig build is no fun on a tiny laptop. So would it be better to have better profiled kernels, obviating the need for an almost full build? Hell yeah! I also hate having to enable support for modules. A non-modular build is quicker to build and avoids some security issues. Some drivers don't work well built-in (they load firmware etc too early), but imho it's worth doing if you can, and it's something we should make easy for people to do because of the security side (of course, per-build randomly generated keys and signed modules with the keys deleted after the build would be reasonably equivalent from a security standpoint, but we're not there yet). Agreed. So there are some not-so-obscure situations, judging by your examples above. Ho-humm. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, 2012-07-19 at 19:34 +0200, Borislav Petkov wrote: I can pass the above to a allnoconfig, and the box will boot and allow ssh. Note, the reason for the serial config, is that this ktest run uses a serial port to see if the box booted. If the serial isn't there, then it thinks it failed. I agree with all this and you've explained this to me live already so you're preaching to the choir. Yes, I know you know this already, as we discussed it in a pub over a beer (choir practice). But this is a public forum on LKML (the church), where I now have an audience of heathens. Convert! Convert! You are all sinners! But it would be a lot faster/easier if users can select, let's call'em profiles which are not mutually exclusive and can speed up the configuration process. They can either be distro-specific or generic, selecting certain features you need. So configuring your kernel would be like shopping without paying too much attention to details. Let's look into the head of a person doing a config like that and read some of her thoughts :): Hm, ok, this new configurator is cool, a lot faster I gotta say... So, what do I need, ah, yes, it is an AMD laptop so from vendors I select AMD, then I probably need ext4, then I'd like to do packet filtering so I should enable iptables.. Oh, I'd like to do tracing too so let's enable tracing and trust Steven with the options he's added by default, then I need ahci, I'd also like to do encrypted partitions so I'll enable device mapper with crypto... So all those things could be selectable from that profiles menu without having to go through the gazillion of little suboptions and having to read help (which is sometimes completely helpless) and figure out do I need it or not. And this would simplify configuration a lot. IMHO, anyway. I totally agree with this. It would be nice to have a profile list where you can pick and chose what you have installed: network nfs ext3 serial xen kvm etc etc Where you can pick and choose what general features you want and it selects all the core infrastructure to get those features usable. It wouldn't select the device modules needed, you will still need to select what hardware you have. But it gets most of the work done for you. But this still doesn't solve Linus's initial request. That would be a single option that makes your distro boot, and work well. Again, that option wont have the drivers needed, but it will enable all the core infrastructure that you need. Going with my /usr/share/Linux/Kconfig, this could use the profile options as well. And just select those that are required. But then again, Linus did want a minimum selection of stuff. Side note (again), IIRC, select has a bug. If you have Config X selecting config Y but Y depends on Z, if you enable X, it will enable Y without enabling Z. I think there were some patches to address this, but I don't remember. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 01:57:26PM -0400, Steven Rostedt wrote: Yes, I know you know this already, as we discussed it in a pub over a beer (choir practice). But this is a public forum on LKML (the church), where I now have an audience of heathens. Convert! Convert! You are all sinners! Ah, gotcha. [ … ] But this still doesn't solve Linus's initial request. That would be a single option that makes your distro boot, and work well. Again, that option wont have the drivers needed, but it will enable all the core infrastructure that you need. Oh I'm being additive here. You'll have feature profiles for the stuff we talk above and distro profiles which solve Linus' issue. Basically one coarse-grained config option will either select a feature which has a lot of small subfeatures of which some are sane and want to be enabled by default when selecting the topfeature. Or a distro-specific feature which could itself select other topfeatures. I haven't tried this in reality to actually be able to say that a tree-like configure approach would actually make sense and work. It sounds like a nice idea though, especially having the hierarchical structure. :) -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, Jul 19, 2012 at 07:53:10PM +0200, Borislav Petkov wrote: On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote: On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov b...@amd64.org wrote: Seriously, this helps only in the cases where the stuff the distro actually needs is in modules. So, there probably are obscure situations where you need to enable stuff which is bool and not M. Sadly, not obscure at all. Most of the *drivers* are modules, but most of the distro config options are indeed booleans (or, if tristate, =y). Even driver-wise, there are some things that are often =y, even though you generally don't want them. Tell me about it. I'm always pissed off when someone thinks his stuff is very important and sets his sacred option to be =y/=m by default so the wider audience can at least compile-test it while the majority of the machines don't actually need it. A more coarse-grained config where most of the stuff is off by default could take care of that probably. PCMCIA? Not even *laptops* have that shit any more, but having built-in cardbus support almost certainly helps in a distro kernel for booting of certain odder cases. Yeah, distros need the one-size-fits-all thing so they have to enable *everything*. Xen support? Odd partition tables? All the different AGP versions? Many of us couldn't care less, but again, it makes sense in the actual distro kernel, even if it does *not* necessarily make sense in a personalized one. Yep. I proposed something that would solve some of this - but not during compile time but rather during boot-time [http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/99.html] (interestingly enough hpa was first to propose it 10 years ago :-) The goal is turn built-in components in well, unloadable components. That way you won't have at least that much stuff laying around not being used. Not the full silver bullet, but at least it gets some of this stuff out of the way and you don't have to worry about the extra stuff that was built-in. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
* da...@lang.hm wrote: > On Wed, 18 Jul 2012, Ingo Molnar wrote: > > >* da...@lang.hm wrote: > > > >>>Anybody who says "I want to run Fedora without SELINUX > >>>because I do my own security development" is by *definition* > >>>not relevant to the whole feature. > >> > >>Don't mistake the example for the feature. the SELINUX thing > >>is just an example. As Alan Cox commented, taking a distro > >>config and disabling one thing is a common troubleshooting > >>request from kernel developers. > > > >It's still irrelevant: > > > >- if a user chooses a distro config it means that he is using > > that distro. Disabling an essential component of the distro > > config, even if a kernel developer asks for it, will likely > > break that distro and is thus a dumb thing to do. (the > > typical user will also be unlikely to be *able* to edit a > > .config and make sure it works.) > > that's assuming that everything listed really is essential. See the requirements in Linus's earlier mail: -> The *two* requirements (and they're really the same theme) I personally think we should have for this are - I think every single "select" for these things should come with a comment about what it is about and why the distro needs it (to show there was some thought involved and not just a blind "took it from the distro config") - It should be about *minimal* settings. I'd rather have too few things and the occasional complaint about "oh, it didn't work because it missed XYZ" than have it grow to contain all the options just because somebody decided to just add random things until things worked. <- Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Wed, 18 Jul 2012, Ingo Molnar wrote: * da...@lang.hm wrote: Anybody who says "I want to run Fedora without SELINUX because I do my own security development" is by *definition* not relevant to the whole feature. Don't mistake the example for the feature. the SELINUX thing is just an example. As Alan Cox commented, taking a distro config and disabling one thing is a common troubleshooting request from kernel developers. It's still irrelevant: - if a user chooses a distro config it means that he is using that distro. Disabling an essential component of the distro config, even if a kernel developer asks for it, will likely break that distro and is thus a dumb thing to do. (the typical user will also be unlikely to be *able* to edit a .config and make sure it works.) that's assuming that everything listed really is essential. The history of features defaulting to 'Y' in the existing kernel config doesn't give me great confidence that reality will be anywhere close to this ideal. - Furthermore, there's *already* over ten thousand select's in our Kconfig's, and it's already hard at times to disable dependent options. - I've been using what Linus suggested for many years via private patches to do bootable randconfig testing and the concept works just fine - enabling a distro specific minconfig is absolutely useful, I'm glad it's being pursued upstream as well... So what you are arguing about is IMO irrelevant, it is immaterial to the problem at hand and the concept works just fine in practice. Shrug, you guys have to maintain the result, I'm just a user. But I don't see why the same logic that kept the kernel installation outside of the makefiles and created /sbin/installkernel wouldn't also apply here. using a separate miniconfig in a known place would seem to be less code, distribute the work better (as every distro can use it without having to patch the same files in the kernel source), and be more flexible. Flexibility has a way of being leveraged in ways never imagined initially, so if it can be gained without complicating the code (and it's maintinance), and the initial use case, I always tend to push for the more flexible option. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Wed, 18 Jul 2012, Ingo Molnar wrote: * da...@lang.hm da...@lang.hm wrote: Anybody who says I want to run Fedora without SELINUX because I do my own security development is by *definition* not relevant to the whole feature. Don't mistake the example for the feature. the SELINUX thing is just an example. As Alan Cox commented, taking a distro config and disabling one thing is a common troubleshooting request from kernel developers. It's still irrelevant: - if a user chooses a distro config it means that he is using that distro. Disabling an essential component of the distro config, even if a kernel developer asks for it, will likely break that distro and is thus a dumb thing to do. (the typical user will also be unlikely to be *able* to edit a .config and make sure it works.) that's assuming that everything listed really is essential. The history of features defaulting to 'Y' in the existing kernel config doesn't give me great confidence that reality will be anywhere close to this ideal. - Furthermore, there's *already* over ten thousand select's in our Kconfig's, and it's already hard at times to disable dependent options. - I've been using what Linus suggested for many years via private patches to do bootable randconfig testing and the concept works just fine - enabling a distro specific minconfig is absolutely useful, I'm glad it's being pursued upstream as well... So what you are arguing about is IMO irrelevant, it is immaterial to the problem at hand and the concept works just fine in practice. Shrug, you guys have to maintain the result, I'm just a user. But I don't see why the same logic that kept the kernel installation outside of the makefiles and created /sbin/installkernel wouldn't also apply here. using a separate miniconfig in a known place would seem to be less code, distribute the work better (as every distro can use it without having to patch the same files in the kernel source), and be more flexible. Flexibility has a way of being leveraged in ways never imagined initially, so if it can be gained without complicating the code (and it's maintinance), and the initial use case, I always tend to push for the more flexible option. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
* da...@lang.hm da...@lang.hm wrote: On Wed, 18 Jul 2012, Ingo Molnar wrote: * da...@lang.hm da...@lang.hm wrote: Anybody who says I want to run Fedora without SELINUX because I do my own security development is by *definition* not relevant to the whole feature. Don't mistake the example for the feature. the SELINUX thing is just an example. As Alan Cox commented, taking a distro config and disabling one thing is a common troubleshooting request from kernel developers. It's still irrelevant: - if a user chooses a distro config it means that he is using that distro. Disabling an essential component of the distro config, even if a kernel developer asks for it, will likely break that distro and is thus a dumb thing to do. (the typical user will also be unlikely to be *able* to edit a .config and make sure it works.) that's assuming that everything listed really is essential. See the requirements in Linus's earlier mail: - The *two* requirements (and they're really the same theme) I personally think we should have for this are - I think every single select for these things should come with a comment about what it is about and why the distro needs it (to show there was some thought involved and not just a blind took it from the distro config) - It should be about *minimal* settings. I'd rather have too few things and the occasional complaint about oh, it didn't work because it missed XYZ than have it grow to contain all the options just because somebody decided to just add random things until things worked. - Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, Jul 16, 2012 at 10:56 PM, Linus Torvalds
wrote:
> On Mon, Jul 16, 2012 at 12:26 PM, wrote:
>> Some of the proposed ways to implement the minimum distro kernel would not
>> allow you to override the distro defaults because they would be implemented
>> by setting dependancies, not by selecting options that you as the user could
>> then unselect.
>
> The sanest thing to do is just a list of "select" statements. And in
> any case it would have to depend on the "distro config" entry, so EVEN
> THEN you could just create the Kconfig file, then edit out the distro
> config thing, and then do whatever you want.
Except that "select" is one of the ugliest things in Kconfig, as it
blindly sets a symbol
without checking if its dependencies are fulfilled.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, Jul 16, 2012 at 10:56 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Jul 16, 2012 at 12:26 PM, da...@lang.hm wrote:
Some of the proposed ways to implement the minimum distro kernel would not
allow you to override the distro defaults because they would be implemented
by setting dependancies, not by selecting options that you as the user could
then unselect.
The sanest thing to do is just a list of select statements. And in
any case it would have to depend on the distro config entry, so EVEN
THEN you could just create the Kconfig file, then edit out the distro
config thing, and then do whatever you want.
Except that select is one of the ugliest things in Kconfig, as it
blindly sets a symbol
without checking if its dependencies are fulfilled.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, 16 Jul 2012, Linus Torvalds wrote: On Mon, Jul 16, 2012 at 12:26 PM, wrote: Some of the proposed ways to implement the minimum distro kernel would not allow you to override the distro defaults because they would be implemented by setting dependancies, not by selecting options that you as the user could then unselect. The sanest thing to do is just a list of "select" statements. And in any case it would have to depend on the "distro config" entry, so EVEN THEN you could just create the Kconfig file, then edit out the distro config thing, and then do whatever you want. So I don't see why you're arguing. Even if it is very much a "if you select the FEDORA_X kconfig option, that will automatically force all those other options on", I don't see why you are so upset. Just set it, generate your kconfig, and then edit to file to NOT set the distro config. Then you can do whatever the hell you want. What I'm upset about is simply the fact that EVEN IF your arguments were valid (and I don't think they are: see above for trivial fix) I think your arguments are bogus, for the simple reason that what you ask for isn't even what the whole "distro minconfig" is at all about. It's about normal users who absolutely DO NOT want to edit the config. People who want to say "I know I have intel/amd/nvidia graphics, standard USB, and no CD-ROM drive". They couldn't care *less* about SELINUX, and in fact that very issue is why we should have this. Anybody who says "I want to run Fedora without SELINUX because I do my own security development" is by *definition* not relevant to the whole feature. Don't mistake the example for the feature. the SELINUX thing is just an example. As Alan Cox commented, taking a distro config and disabling one thing is a common troubleshooting request from kernel developers. I am not that familiar with the internals of kconfig, but my understanding was that if you select feature X that then turns on A, B, and C, if you then edit the .config file to remove feature X features A, B, and C will be turned off the next time you do a make *config. If this is not the case, then it's not as horrible as I was thinking. However, there's still the question of how many different variations of how many different distros are you going to accept into the upstream kernel. How many different versions of Fedora are you going to be willing to have in the menu? This seems to me to be the defconfig problem multiplied by many distros and many versions of each distro. If we can eliminate this combinational explosion by referencing something outside of the kernel tree, it seems to me that it's a big win. As Alan Cox put it in code make distroconfig [cp /etc/system-kconfig(.$ARCH?) .config make oldconfig] make menuconfig (if you want to customise) with the distros providing /etc/system-kconfig files seems far more scalable as well as far more flexible than either setting up a lot of dependancies for new tags or adding a field to every option to make it part of some profile. This approach works both for the users who just want to say "I know I have intel/amd/nvidia graphics, standard USB, and no CD-ROM drive", for the users who know a bit more, but want to start with a known point, and for the production sysadmins who want to use the same mechanism for other purposes (standardizing builds for systems as kernel versions move forward) David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, Jul 16, 2012 at 12:26 PM, wrote: > > Some of the proposed ways to implement the minimum distro kernel would not > allow you to override the distro defaults because they would be implemented > by setting dependancies, not by selecting options that you as the user could > then unselect. The sanest thing to do is just a list of "select" statements. And in any case it would have to depend on the "distro config" entry, so EVEN THEN you could just create the Kconfig file, then edit out the distro config thing, and then do whatever you want. So I don't see why you're arguing. Even if it is very much a "if you select the FEDORA_X kconfig option, that will automatically force all those other options on", I don't see why you are so upset. Just set it, generate your kconfig, and then edit to file to NOT set the distro config. Then you can do whatever the hell you want. What I'm upset about is simply the fact that EVEN IF your arguments were valid (and I don't think they are: see above for trivial fix) I think your arguments are bogus, for the simple reason that what you ask for isn't even what the whole "distro minconfig" is at all about. It's about normal users who absolutely DO NOT want to edit the config. People who want to say "I know I have intel/amd/nvidia graphics, standard USB, and no CD-ROM drive". They couldn't care *less* about SELINUX, and in fact that very issue is why we should have this. Anybody who says "I want to run Fedora without SELINUX because I do my own security development" is by *definition* not relevant to the whole feature. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, 16 Jul 2012, Linus Torvalds wrote: On Mon, Jul 16, 2012 at 9:43 AM, wrote: The problem is that you can't select the Fedora profile and then unselect SELINUX, so the profile will do you no good. Guys, stop it now. Your "problem" isn't what any sane person cares about, and isn't what I started the RFC for. Seriously. NOBODY CARES. You can do what you want to do *today*. Just edit the config file, or use any of the millions of config tools. Stop whining. The thing I'm asking for is for normal people. Make it easy for people who DO NOT CARE about the config file to just build a kernel for their machine. Don't complicate the issue by bringing up some totally unrelated question. Don't derail a useful feature for the 99% because you're not in it. Some of the proposed ways to implement the minimum distro kernel would not allow you to override the distro defaults because they would be implemented by setting dependancies, not by selecting options that you as the user could then unselect. If you have to edit the .config file, and then have your next make *config override your edits (due to dependancy resolution) and so have to edit the .config file again this is a really ugly way of working. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
Dear all, I usually don't take part of discussions in LKML but I recognized myself in what Linus is actually describing as a "normal user" (one of the few insane enough to read the mailing list...) so I wrote a few ideas below... Please give me your thoughts Benjamin On 7/16/12 6:50 PM, "Linus Torvalds" wrote: >Your "problem" isn't what any sane person cares about, and isn't what >I started the RFC for. >Seriously. NOBODY CARES. >You can do what you want to do *today*. Just edit the config file, or >use any of the millions of config tools. Stop whining. I guess the complexity of configuration in order to build a distro is why I didn't even try to build a distro-specific kernel Moreover the doc is terrible for unfamiliar users... >The thing I'm asking for is for normal people. Make it easy for people >who DO NOT CARE about the config file to just build a kernel for their >machine. If you think about users like me who just want to build a basic featured kernel we always do a make menuconfig with near default options... What I would expect to build a distro/kernel is to have access in a menuconfig-like to 1) basic features like networking, usb storage, power management etc _enabled by default_ so I can quickly build a "common platform" kernel which gives me everything I need on my laptop and 2) have a menu like "*distro* basic requirements" (never changes and only for a few big distros) and finally 3) have a "*distro* advanced" menu having all the other non-mandatory options available but with a conflict manager (it could check against a full Kconfig file kept up-to-date by each distro groups) Without necessary talking of menuconfig, I liked very much the structure Linus suggested in the first post regarding Kconfig files That maybe some idiotic suggestions but I'd like to know what you think about it anyway Cheers! B. >Don't complicate the issue by bringing up some totally unrelated >question. Don't derail a useful feature for the 99% because you're not >in it. > >Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, 16 Jul 2012, Alan Cox wrote: Select the profile and then fixup the config the normal way. If what the admin wants is incompatible with the profile, admin doesn't select the profile. Thats ugly - "distro except..." is a standard thing you ask users to do for debugging. However providing you separate the initial profile from the later tools it simply becomes make distroconfig [cp /etc/system-kconfig(.$ARCH?) .config make oldconfig] make menuconfig (if you want to customise) In addition the make oldconfig means you can ship a deliberately incomplete distroconfig and get the user asked some bits. exactly what I was fumbling to describe, thanks. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
> Select the profile and then fixup the config the normal way. > > If what the admin wants is incompatible with the profile, admin doesn't > select the profile. Thats ugly - "distro except..." is a standard thing you ask users to do for debugging. However providing you separate the initial profile from the later tools it simply becomes make distroconfig [cp /etc/system-kconfig(.$ARCH?) .config make oldconfig] make menuconfig (if you want to customise) In addition the make oldconfig means you can ship a deliberately incomplete distroconfig and get the user asked some bits. make -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, Jul 16, 2012 at 9:43 AM, wrote: > > The problem is that you can't select the Fedora profile and then unselect > SELINUX, so the profile will do you no good. Guys, stop it now. Your "problem" isn't what any sane person cares about, and isn't what I started the RFC for. Seriously. NOBODY CARES. You can do what you want to do *today*. Just edit the config file, or use any of the millions of config tools. Stop whining. The thing I'm asking for is for normal people. Make it easy for people who DO NOT CARE about the config file to just build a kernel for their machine. Don't complicate the issue by bringing up some totally unrelated question. Don't derail a useful feature for the 99% because you're not in it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 03:09:12PM -0700, da...@lang.hm wrote: > On Mon, 16 Jul 2012, Cyrill Gorcunov wrote: > > >Replying to David's message (sorry for delay) I fear having a bunch of > >miniconfig files will end up in a mess. Maybe (maybe (!) I don't know since > >I've no time at moment to read kconfig code and I'm not sure if this > >is right direction at all) it would worth to add some new keyword to > >kconfig language, say "profile", which would tag symbol to a category > >if needed, and these categories included into profiles automatically. > >On the other hands this might end up in a mess as well. > > I have a couple problems with the approach of modifying the existing > kconfig files > > 1. how does it handle the case when a profile wants something one > way and the admin wants it another way Select the profile and then fixup the config the normal way. If what the admin wants is incompatible with the profile, admin doesn't select the profile. > the example is the fedora default wanting SELINUX and I want some > other LSM Currently, if you run fedora and want something that's not enabled, you recompile your kernel too, right? > 2. since it requires making changes in the upstream kernel source, the > number of people who can make these changes is small. I think that's moot since you either select the profile or you don't. > 3. since all these changes go into the upstream kernel source, changes > to these profiles are going to be visible churn (think of the issues > with the defconfigs for ARM a couple of years ago) AFAICT, those changes will be needed only for a new distro release and that happens twice a year, tops. > 4. the complexity of tagging all possible profiles is very high. That's why we start simple. > Even if you limit the profiles to "Linux Distros", how many different > distros are there? Do you really want to have to start arguing over > which distros are large enough to get their profile added to the > upstream kernel source? That's a valid question; its answer could be defined arbitrarily. Let's say all distros which make money - more than a certain large amount - are allowed. :-) > If instead we go with something along the lines of the miniconf > approach, the picture looks very different > > 1. this approach only sets things one time, after that the person > doing the compile is free to change anything. ... Sorry, I don't see the simplification: you need to rebuild your kernel anyway and before you rebuild it, you can do all the changes you want. So either you select a profile or you load a miniconfig, it doesn't really matter how you do it? -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 03:09:12PM -0700, da...@lang.hm wrote: On Mon, 16 Jul 2012, Cyrill Gorcunov wrote: Replying to David's message (sorry for delay) I fear having a bunch of miniconfig files will end up in a mess. Maybe (maybe (!) I don't know since I've no time at moment to read kconfig code and I'm not sure if this is right direction at all) it would worth to add some new keyword to kconfig language, say profile, which would tag symbol to a category if needed, and these categories included into profiles automatically. On the other hands this might end up in a mess as well. I have a couple problems with the approach of modifying the existing kconfig files 1. how does it handle the case when a profile wants something one way and the admin wants it another way Select the profile and then fixup the config the normal way. If what the admin wants is incompatible with the profile, admin doesn't select the profile. the example is the fedora default wanting SELINUX and I want some other LSM Currently, if you run fedora and want something that's not enabled, you recompile your kernel too, right? 2. since it requires making changes in the upstream kernel source, the number of people who can make these changes is small. I think that's moot since you either select the profile or you don't. 3. since all these changes go into the upstream kernel source, changes to these profiles are going to be visible churn (think of the issues with the defconfigs for ARM a couple of years ago) AFAICT, those changes will be needed only for a new distro release and that happens twice a year, tops. 4. the complexity of tagging all possible profiles is very high. That's why we start simple. Even if you limit the profiles to Linux Distros, how many different distros are there? Do you really want to have to start arguing over which distros are large enough to get their profile added to the upstream kernel source? That's a valid question; its answer could be defined arbitrarily. joshing Let's say all distros which make money - more than a certain large amount - are allowed. :-) /joshing If instead we go with something along the lines of the miniconf approach, the picture looks very different 1. this approach only sets things one time, after that the person doing the compile is free to change anything. ... Sorry, I don't see the simplification: you need to rebuild your kernel anyway and before you rebuild it, you can do all the changes you want. So either you select a profile or you load a miniconfig, it doesn't really matter how you do it? -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, Jul 16, 2012 at 9:43 AM, da...@lang.hm wrote: The problem is that you can't select the Fedora profile and then unselect SELINUX, so the profile will do you no good. Guys, stop it now. Your problem isn't what any sane person cares about, and isn't what I started the RFC for. Seriously. NOBODY CARES. You can do what you want to do *today*. Just edit the config file, or use any of the millions of config tools. Stop whining. The thing I'm asking for is for normal people. Make it easy for people who DO NOT CARE about the config file to just build a kernel for their machine. Don't complicate the issue by bringing up some totally unrelated question. Don't derail a useful feature for the 99% because you're not in it. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
Select the profile and then fixup the config the normal way. If what the admin wants is incompatible with the profile, admin doesn't select the profile. Thats ugly - distro except... is a standard thing you ask users to do for debugging. However providing you separate the initial profile from the later tools it simply becomes make distroconfig [cp /etc/system-kconfig(.$ARCH?) .config make oldconfig] make menuconfig (if you want to customise) In addition the make oldconfig means you can ship a deliberately incomplete distroconfig and get the user asked some bits. make -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, 16 Jul 2012, Alan Cox wrote: Select the profile and then fixup the config the normal way. If what the admin wants is incompatible with the profile, admin doesn't select the profile. Thats ugly - distro except... is a standard thing you ask users to do for debugging. However providing you separate the initial profile from the later tools it simply becomes make distroconfig [cp /etc/system-kconfig(.$ARCH?) .config make oldconfig] make menuconfig (if you want to customise) In addition the make oldconfig means you can ship a deliberately incomplete distroconfig and get the user asked some bits. exactly what I was fumbling to describe, thanks. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
Dear all, I usually don't take part of discussions in LKML but I recognized myself in what Linus is actually describing as a normal user (one of the few insane enough to read the mailing list...) so I wrote a few ideas below... Please give me your thoughts Benjamin On 7/16/12 6:50 PM, Linus Torvalds torva...@linux-foundation.org wrote: Your problem isn't what any sane person cares about, and isn't what I started the RFC for. Seriously. NOBODY CARES. You can do what you want to do *today*. Just edit the config file, or use any of the millions of config tools. Stop whining. I guess the complexity of configuration in order to build a distro is why I didn't even try to build a distro-specific kernel Moreover the doc is terrible for unfamiliar users... The thing I'm asking for is for normal people. Make it easy for people who DO NOT CARE about the config file to just build a kernel for their machine. If you think about users like me who just want to build a basic featured kernel we always do a make menuconfig with near default options... What I would expect to build a distro/kernel is to have access in a menuconfig-like to 1) basic features like networking, usb storage, power management etc _enabled by default_ so I can quickly build a common platform kernel which gives me everything I need on my laptop and 2) have a menu like *distro* basic requirements (never changes and only for a few big distros) and finally 3) have a *distro* advanced menu having all the other non-mandatory options available but with a conflict manager (it could check against a full Kconfig file kept up-to-date by each distro groups) Without necessary talking of menuconfig, I liked very much the structure Linus suggested in the first post regarding Kconfig files That maybe some idiotic suggestions but I'd like to know what you think about it anyway Cheers! B. Don't complicate the issue by bringing up some totally unrelated question. Don't derail a useful feature for the 99% because you're not in it. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, 16 Jul 2012, Linus Torvalds wrote: On Mon, Jul 16, 2012 at 9:43 AM, da...@lang.hm wrote: The problem is that you can't select the Fedora profile and then unselect SELINUX, so the profile will do you no good. Guys, stop it now. Your problem isn't what any sane person cares about, and isn't what I started the RFC for. Seriously. NOBODY CARES. You can do what you want to do *today*. Just edit the config file, or use any of the millions of config tools. Stop whining. The thing I'm asking for is for normal people. Make it easy for people who DO NOT CARE about the config file to just build a kernel for their machine. Don't complicate the issue by bringing up some totally unrelated question. Don't derail a useful feature for the 99% because you're not in it. Some of the proposed ways to implement the minimum distro kernel would not allow you to override the distro defaults because they would be implemented by setting dependancies, not by selecting options that you as the user could then unselect. If you have to edit the .config file, and then have your next make *config override your edits (due to dependancy resolution) and so have to edit the .config file again this is a really ugly way of working. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, Jul 16, 2012 at 12:26 PM, da...@lang.hm wrote: Some of the proposed ways to implement the minimum distro kernel would not allow you to override the distro defaults because they would be implemented by setting dependancies, not by selecting options that you as the user could then unselect. The sanest thing to do is just a list of select statements. And in any case it would have to depend on the distro config entry, so EVEN THEN you could just create the Kconfig file, then edit out the distro config thing, and then do whatever you want. So I don't see why you're arguing. Even if it is very much a if you select the FEDORA_X kconfig option, that will automatically force all those other options on, I don't see why you are so upset. Just set it, generate your kconfig, and then edit to file to NOT set the distro config. Then you can do whatever the hell you want. What I'm upset about is simply the fact that EVEN IF your arguments were valid (and I don't think they are: see above for trivial fix) I think your arguments are bogus, for the simple reason that what you ask for isn't even what the whole distro minconfig is at all about. It's about normal users who absolutely DO NOT want to edit the config. People who want to say I know I have intel/amd/nvidia graphics, standard USB, and no CD-ROM drive. They couldn't care *less* about SELINUX, and in fact that very issue is why we should have this. Anybody who says I want to run Fedora without SELINUX because I do my own security development is by *definition* not relevant to the whole feature. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, 16 Jul 2012, Linus Torvalds wrote: On Mon, Jul 16, 2012 at 12:26 PM, da...@lang.hm wrote: Some of the proposed ways to implement the minimum distro kernel would not allow you to override the distro defaults because they would be implemented by setting dependancies, not by selecting options that you as the user could then unselect. The sanest thing to do is just a list of select statements. And in any case it would have to depend on the distro config entry, so EVEN THEN you could just create the Kconfig file, then edit out the distro config thing, and then do whatever you want. So I don't see why you're arguing. Even if it is very much a if you select the FEDORA_X kconfig option, that will automatically force all those other options on, I don't see why you are so upset. Just set it, generate your kconfig, and then edit to file to NOT set the distro config. Then you can do whatever the hell you want. What I'm upset about is simply the fact that EVEN IF your arguments were valid (and I don't think they are: see above for trivial fix) I think your arguments are bogus, for the simple reason that what you ask for isn't even what the whole distro minconfig is at all about. It's about normal users who absolutely DO NOT want to edit the config. People who want to say I know I have intel/amd/nvidia graphics, standard USB, and no CD-ROM drive. They couldn't care *less* about SELINUX, and in fact that very issue is why we should have this. Anybody who says I want to run Fedora without SELINUX because I do my own security development is by *definition* not relevant to the whole feature. Don't mistake the example for the feature. the SELINUX thing is just an example. As Alan Cox commented, taking a distro config and disabling one thing is a common troubleshooting request from kernel developers. I am not that familiar with the internals of kconfig, but my understanding was that if you select feature X that then turns on A, B, and C, if you then edit the .config file to remove feature X features A, B, and C will be turned off the next time you do a make *config. If this is not the case, then it's not as horrible as I was thinking. However, there's still the question of how many different variations of how many different distros are you going to accept into the upstream kernel. How many different versions of Fedora are you going to be willing to have in the menu? This seems to me to be the defconfig problem multiplied by many distros and many versions of each distro. If we can eliminate this combinational explosion by referencing something outside of the kernel tree, it seems to me that it's a big win. As Alan Cox put it in code make distroconfig [cp /etc/system-kconfig(.$ARCH?) .config make oldconfig] make menuconfig (if you want to customise) with the distros providing /etc/system-kconfig files seems far more scalable as well as far more flexible than either setting up a lot of dependancies for new tags or adding a field to every option to make it part of some profile. This approach works both for the users who just want to say I know I have intel/amd/nvidia graphics, standard USB, and no CD-ROM drive, for the users who know a bit more, but want to start with a known point, and for the production sysadmins who want to use the same mechanism for other purposes (standardizing builds for systems as kernel versions move forward) David Lang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, 16 Jul 2012, Cyrill Gorcunov wrote: On Sun, Jul 15, 2012 at 03:09:12PM -0700, da...@lang.hm wrote: 3. by simply combining miniconfig files, you can combine sets of pre-defined options Wait, David, I'm lost. These miniconfigs should live somewhere on my home directory (if they are out of mainline tree)? the distro provided miniconfig files should live in a "known location" (like the distro specific scripts for "make install", but I'm saying that we should be able to use this same mechanism to include locally generated files. combining external files doesn't need to be the job of the kernel kconfig infrastructure either. There could be external scripts that take one or more distro provided files and one or more local files and combine them for the kconfig infrastructure. For a distro, I could see their build farm using this as well, with a file organization along the lines of base config arch specific options (one per arch) generic drivers (USB devices, etc) This sort of thing would help reduce the chances of there being unexpected differences between the different architecture builds. this can be done without having to modify the existing kconfig stuff at all (by using make oldconfig), but it's likely that a little bit of support from kconfig could make creating these miniconifg files much easier. Linus started off wanting the core requirements, other people want to duplicate the full distro kernel, others want everything but the drivers, others want to substatute a list of driver options that their local systems need, etc. by using separate files that are external to the kconfig files in the kernel.org source tree, I think that all these people can be satisfied without an explosion of complexity in the source tree. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 03:09:12PM -0700, da...@lang.hm wrote: > > 3. by simply combining miniconfig files, you can combine sets of > pre-defined options Wait, David, I'm lost. These miniconfigs should live somewhere on my home directory (if they are out of mainline tree)? Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, 16 Jul 2012, Cyrill Gorcunov wrote: Replying to David's message (sorry for delay) I fear having a bunch of miniconfig files will end up in a mess. Maybe (maybe (!) I don't know since I've no time at moment to read kconfig code and I'm not sure if this is right direction at all) it would worth to add some new keyword to kconfig language, say "profile", which would tag symbol to a category if needed, and these categories included into profiles automatically. On the other hands this might end up in a mess as well. I have a couple problems with the approach of modifying the existing kconfig files 1. how does it handle the case when a profile wants something one way and the admin wants it another way the example is the fedora default wanting SELINUX and I want some other LSM 2. since it requires making changes in the upstream kernel source, the number of people who can make these changes is small. 3. since all these changes go into the upstream kernel source, changes to these profiles are going to be visible churn (think of the issues with the defconfigs for ARM a couple of years ago) 4. the complexity of tagging all possible profiles is very high. Even if you limit the profiles to "Linux Distros", how many different distros are there? Do you really want to have to start arguing over which distros are large enough to get their profile added to the upstream kernel source? If instead we go with something along the lines of the miniconf approach, the picture looks very different 1. this approach only sets things one time, after that the person doing the compile is free to change anything. 2. since the changes are a local file, separate from the upstream source, issues like who can provide the config, what distros will accept it, complexity in having many different options, etc all vanish 3. by simply combining miniconfig files, you can combine sets of pre-defined options David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 11:18:48PM +0200, Borislav Petkov wrote: > On Sun, Jul 15, 2012 at 01:17:16PM +0300, Pekka Enberg wrote: > > > Yes, something like KVMTOOL_TEST_ENABLE except not a make target but a > > > Kconfig option. > > > > It is a config option too - "make kvmconfig" simply enables it. > > Right, so how about something more concrete in this whole discussion: > > Maybe add the KVMTOOL_TEST_ENABLE (maybe rename it to a more fitting > name like KVM_OPTS or similar) thing to a new toplevel Kconfig menu > called "Distro and other profiles" or so: > > │ │ General setup ---> > │ │ Distros and other profiles ---><--- > │ │ [*] Enable loadable module support ---> > │ │ [*] Enable the block layer ---> > │ │ Processor type and features ---> > ... > > Btw, which Kconfig option is needed for "-usbdevice tablet" support so > that the host mouse can be able to send scroll events to the guest qemu > screen without the need for the qemu screen to capture it so that I need > to "escape" it everytime I need to return to the host? And can we add it > to the list of options KVMTOOL_TEST_ENABLE selects? All this is pretty promising idea for usability I think (plain "Profiles" is enough if not only distros will be there methink). Replying to David's message (sorry for delay) I fear having a bunch of miniconfig files will end up in a mess. Maybe (maybe (!) I don't know since I've no time at moment to read kconfig code and I'm not sure if this is right direction at all) it would worth to add some new keyword to kconfig language, say "profile", which would tag symbol to a category if needed, and these categories included into profiles automatically. On the other hands this might end up in a mess as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 01:17:16PM +0300, Pekka Enberg wrote: > > Yes, something like KVMTOOL_TEST_ENABLE except not a make target but a > > Kconfig option. > > It is a config option too - "make kvmconfig" simply enables it. Right, so how about something more concrete in this whole discussion: Maybe add the KVMTOOL_TEST_ENABLE (maybe rename it to a more fitting name like KVM_OPTS or similar) thing to a new toplevel Kconfig menu called "Distro and other profiles" or so: │ │ General setup ---> │ │ Distros and other profiles ---> <--- │ │ [*] Enable loadable module support ---> │ │ [*] Enable the block layer ---> │ │ Processor type and features ---> ... Btw, which Kconfig option is needed for "-usbdevice tablet" support so that the host mouse can be able to send scroll events to the guest qemu screen without the need for the qemu screen to capture it so that I need to "escape" it everytime I need to return to the host? And can we add it to the list of options KVMTOOL_TEST_ENABLE selects? Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 1:14 PM, Borislav Petkov wrote: > On Sat, Jul 14, 2012 at 03:12:05PM +0300, Pekka Enberg wrote: >> We have "make kvmconfig" in the KVM tool tree that pretty much does >> that automatically. There's nothing tools/kvm specific about it so I >> guess you could merge that separately. > > Yes, something like KVMTOOL_TEST_ENABLE except not a make target but a > Kconfig option. It is a config option too - "make kvmconfig" simply enables it. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 03:12:05PM +0300, Pekka Enberg wrote: > We have "make kvmconfig" in the KVM tool tree that pretty much does > that automatically. There's nothing tools/kvm specific about it so I > guess you could merge that separately. Yes, something like KVMTOOL_TEST_ENABLE except not a make target but a Kconfig option. I can imagine a user selecting this and other coarse-grained options in Kconfig and then "adjusting" single options like, for example, I wouldn't need the *9P* options on x86, etc, etc. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 03:12:05PM +0300, Pekka Enberg wrote: We have make kvmconfig in the KVM tool tree that pretty much does that automatically. There's nothing tools/kvm specific about it so I guess you could merge that separately. Yes, something like KVMTOOL_TEST_ENABLE except not a make target but a Kconfig option. I can imagine a user selecting this and other coarse-grained options in Kconfig and then adjusting single options like, for example, I wouldn't need the *9P* options on x86, etc, etc. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 1:14 PM, Borislav Petkov b...@amd64.org wrote: On Sat, Jul 14, 2012 at 03:12:05PM +0300, Pekka Enberg wrote: We have make kvmconfig in the KVM tool tree that pretty much does that automatically. There's nothing tools/kvm specific about it so I guess you could merge that separately. Yes, something like KVMTOOL_TEST_ENABLE except not a make target but a Kconfig option. It is a config option too - make kvmconfig simply enables it. Pekka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 01:17:16PM +0300, Pekka Enberg wrote: Yes, something like KVMTOOL_TEST_ENABLE except not a make target but a Kconfig option. It is a config option too - make kvmconfig simply enables it. Right, so how about something more concrete in this whole discussion: Maybe add the KVMTOOL_TEST_ENABLE (maybe rename it to a more fitting name like KVM_OPTS or similar) thing to a new toplevel Kconfig menu called Distro and other profiles or so: │ │ General setup --- │ │ Distros and other profiles --- --- │ │ [*] Enable loadable module support --- │ │ [*] Enable the block layer --- │ │ Processor type and features --- ... Btw, which Kconfig option is needed for -usbdevice tablet support so that the host mouse can be able to send scroll events to the guest qemu screen without the need for the qemu screen to capture it so that I need to escape it everytime I need to return to the host? And can we add it to the list of options KVMTOOL_TEST_ENABLE selects? Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 11:18:48PM +0200, Borislav Petkov wrote: On Sun, Jul 15, 2012 at 01:17:16PM +0300, Pekka Enberg wrote: Yes, something like KVMTOOL_TEST_ENABLE except not a make target but a Kconfig option. It is a config option too - make kvmconfig simply enables it. Right, so how about something more concrete in this whole discussion: Maybe add the KVMTOOL_TEST_ENABLE (maybe rename it to a more fitting name like KVM_OPTS or similar) thing to a new toplevel Kconfig menu called Distro and other profiles or so: │ │ General setup --- │ │ Distros and other profiles ------ │ │ [*] Enable loadable module support --- │ │ [*] Enable the block layer --- │ │ Processor type and features --- ... Btw, which Kconfig option is needed for -usbdevice tablet support so that the host mouse can be able to send scroll events to the guest qemu screen without the need for the qemu screen to capture it so that I need to escape it everytime I need to return to the host? And can we add it to the list of options KVMTOOL_TEST_ENABLE selects? All this is pretty promising idea for usability I think (plain Profiles is enough if not only distros will be there methink). Replying to David's message (sorry for delay) I fear having a bunch of miniconfig files will end up in a mess. Maybe (maybe (!) I don't know since I've no time at moment to read kconfig code and I'm not sure if this is right direction at all) it would worth to add some new keyword to kconfig language, say profile, which would tag symbol to a category if needed, and these categories included into profiles automatically. On the other hands this might end up in a mess as well. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, 16 Jul 2012, Cyrill Gorcunov wrote: Replying to David's message (sorry for delay) I fear having a bunch of miniconfig files will end up in a mess. Maybe (maybe (!) I don't know since I've no time at moment to read kconfig code and I'm not sure if this is right direction at all) it would worth to add some new keyword to kconfig language, say profile, which would tag symbol to a category if needed, and these categories included into profiles automatically. On the other hands this might end up in a mess as well. I have a couple problems with the approach of modifying the existing kconfig files 1. how does it handle the case when a profile wants something one way and the admin wants it another way the example is the fedora default wanting SELINUX and I want some other LSM 2. since it requires making changes in the upstream kernel source, the number of people who can make these changes is small. 3. since all these changes go into the upstream kernel source, changes to these profiles are going to be visible churn (think of the issues with the defconfigs for ARM a couple of years ago) 4. the complexity of tagging all possible profiles is very high. Even if you limit the profiles to Linux Distros, how many different distros are there? Do you really want to have to start arguing over which distros are large enough to get their profile added to the upstream kernel source? If instead we go with something along the lines of the miniconf approach, the picture looks very different 1. this approach only sets things one time, after that the person doing the compile is free to change anything. 2. since the changes are a local file, separate from the upstream source, issues like who can provide the config, what distros will accept it, complexity in having many different options, etc all vanish 3. by simply combining miniconfig files, you can combine sets of pre-defined options David Lang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sun, Jul 15, 2012 at 03:09:12PM -0700, da...@lang.hm wrote: 3. by simply combining miniconfig files, you can combine sets of pre-defined options Wait, David, I'm lost. These miniconfigs should live somewhere on my home directory (if they are out of mainline tree)? Cyrill -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Mon, 16 Jul 2012, Cyrill Gorcunov wrote: On Sun, Jul 15, 2012 at 03:09:12PM -0700, da...@lang.hm wrote: 3. by simply combining miniconfig files, you can combine sets of pre-defined options Wait, David, I'm lost. These miniconfigs should live somewhere on my home directory (if they are out of mainline tree)? the distro provided miniconfig files should live in a known location (like the distro specific scripts for make install, but I'm saying that we should be able to use this same mechanism to include locally generated files. combining external files doesn't need to be the job of the kernel kconfig infrastructure either. There could be external scripts that take one or more distro provided files and one or more local files and combine them for the kconfig infrastructure. For a distro, I could see their build farm using this as well, with a file organization along the lines of base config arch specific options (one per arch) generic drivers (USB devices, etc) This sort of thing would help reduce the chances of there being unexpected differences between the different architecture builds. this can be done without having to modify the existing kconfig stuff at all (by using make oldconfig), but it's likely that a little bit of support from kconfig could make creating these miniconifg files much easier. Linus started off wanting the core requirements, other people want to duplicate the full distro kernel, others want everything but the drivers, others want to substatute a list of driver options that their local systems need, etc. by using separate files that are external to the kconfig files in the kernel.org source tree, I think that all these people can be satisfied without an explosion of complexity in the source tree. David Lang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
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). Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
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. This would simplify not only the configuration process but also Kconfig-related build failures since for your configuration you'll make sure that required stuff is selected. What I'm saying is that not only distro-specific configs but also some sort of hierarchical config options could be defined to automatically preselect stuff for a specific aspect and save a lot of time when configuring a new system. Our config options have grown humongous right about now and we can use the simplification. Of course, you can always do fine-grained tuning afterwards but it'll save a lot of time, in general. Let's have an example: when I have to build upstream on a distro here, I take the distro config and use it despite that it takes a long time to build since everything is module - it is still better for me to wait that one time instead of doing a dozen of trial and errors after forgetting a config option each time. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 03:12:05PM +0300, Pekka Enberg wrote: > On Sat, Jul 14, 2012 at 1:37 PM, Borislav Petkov wrote: > > On Fri, Jul 13, 2012 at 11:41:21PM +0200, richard -rw- weinberger wrote: > >> On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond > >> wrote: > >> > We could at least make selection of a minimal set of drivers for the > >> > more common virtualised platforms a lot easier. > >> > Right now, you need to hunt through 30+ different menus in order to find > >> > what you need to run in a basic KVM virtual machine... > >> > >> Yes, every time I build a kernel to be used on KVM I forget something. :-\ > >> > >> We could introduce a section in Kconfig which contains selections for > >> common use cases. > >> E.g. as Linus requested for minimal distro requirements but also > >> selections for various common > >> guest configurations. > > > > +1. > > > > Same experience with building a kvm kernel so I couldn't agree more. > > We have "make kvmconfig" in the KVM tool tree that pretty much does > that automatically. There's nothing tools/kvm specific about it so I > guess you could merge that separately. Yup, "make kvmconfig" does things right but I guess a general mechanism might be preferred here :) Look, if (at the moment) I'm going to nconfig and virt. section, I see Virtualization Kernel-based Virtual Machine (KVM) support KVM for Intel processors support KVM for AMD processors support Audit KVM MMU Host kernel accelerator for virtio net (EXPERIMENTAL) and everytime I'm here I need to remember where to search for virtio devices I would like to include into config. Though I expect to see in this secrion everything related to virtualization and have a way to turn on virtio-ring and etc. 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. (note, I know how to enable all this and where to lookup for this entries of course, but I guess for regular users it would be easier to enable various virt. features if they are gathered in one place) Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 1:37 PM, Borislav Petkov wrote: > On Fri, Jul 13, 2012 at 11:41:21PM +0200, richard -rw- weinberger wrote: >> On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond >> wrote: >> > We could at least make selection of a minimal set of drivers for the >> > more common virtualised platforms a lot easier. >> > Right now, you need to hunt through 30+ different menus in order to find >> > what you need to run in a basic KVM virtual machine... >> >> Yes, every time I build a kernel to be used on KVM I forget something. :-\ >> >> We could introduce a section in Kconfig which contains selections for >> common use cases. >> E.g. as Linus requested for minimal distro requirements but also >> selections for various common >> guest configurations. > > +1. > > Same experience with building a kvm kernel so I couldn't agree more. We have "make kvmconfig" in the KVM tool tree that pretty much does that automatically. There's nothing tools/kvm specific about it so I guess you could merge that separately. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Fri, Jul 13, 2012 at 11:41:21PM +0200, richard -rw- weinberger wrote: > On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond > wrote: > > We could at least make selection of a minimal set of drivers for the > > more common virtualised platforms a lot easier. > > Right now, you need to hunt through 30+ different menus in order to find > > what you need to run in a basic KVM virtual machine... > > Yes, every time I build a kernel to be used on KVM I forget something. :-\ > > We could introduce a section in Kconfig which contains selections for > common use cases. > E.g. as Linus requested for minimal distro requirements but also > selections for various common > guest configurations. +1. Same experience with building a kvm kernel so I couldn't agree more. Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Fri, Jul 13, 2012 at 11:41:21PM +0200, richard -rw- weinberger wrote: On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond trond.mykleb...@netapp.com wrote: We could at least make selection of a minimal set of drivers for the more common virtualised platforms a lot easier. Right now, you need to hunt through 30+ different menus in order to find what you need to run in a basic KVM virtual machine... Yes, every time I build a kernel to be used on KVM I forget something. :-\ We could introduce a section in Kconfig which contains selections for common use cases. E.g. as Linus requested for minimal distro requirements but also selections for various common guest configurations. +1. Same experience with building a kvm kernel so I couldn't agree more. Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 1:37 PM, Borislav Petkov b...@alien8.de wrote: On Fri, Jul 13, 2012 at 11:41:21PM +0200, richard -rw- weinberger wrote: On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond trond.mykleb...@netapp.com wrote: We could at least make selection of a minimal set of drivers for the more common virtualised platforms a lot easier. Right now, you need to hunt through 30+ different menus in order to find what you need to run in a basic KVM virtual machine... Yes, every time I build a kernel to be used on KVM I forget something. :-\ We could introduce a section in Kconfig which contains selections for common use cases. E.g. as Linus requested for minimal distro requirements but also selections for various common guest configurations. +1. Same experience with building a kvm kernel so I couldn't agree more. We have make kvmconfig in the KVM tool tree that pretty much does that automatically. There's nothing tools/kvm specific about it so I guess you could merge that separately. Pekka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Sat, Jul 14, 2012 at 03:12:05PM +0300, Pekka Enberg wrote: On Sat, Jul 14, 2012 at 1:37 PM, Borislav Petkov b...@alien8.de wrote: On Fri, Jul 13, 2012 at 11:41:21PM +0200, richard -rw- weinberger wrote: On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond trond.mykleb...@netapp.com wrote: We could at least make selection of a minimal set of drivers for the more common virtualised platforms a lot easier. Right now, you need to hunt through 30+ different menus in order to find what you need to run in a basic KVM virtual machine... Yes, every time I build a kernel to be used on KVM I forget something. :-\ We could introduce a section in Kconfig which contains selections for common use cases. E.g. as Linus requested for minimal distro requirements but also selections for various common guest configurations. +1. Same experience with building a kvm kernel so I couldn't agree more. We have make kvmconfig in the KVM tool tree that pretty much does that automatically. There's nothing tools/kvm specific about it so I guess you could merge that separately. Yup, make kvmconfig does things right but I guess a general mechanism might be preferred here :) Look, if (at the moment) I'm going to nconfig and virt. section, I see Virtualization Kernel-based Virtual Machine (KVM) support KVM for Intel processors support KVM for AMD processors support Audit KVM MMU Host kernel accelerator for virtio net (EXPERIMENTAL) and everytime I'm here I need to remember where to search for virtio devices I would like to include into config. Though I expect to see in this secrion everything related to virtualization and have a way to turn on virtio-ring and etc. 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. (note, I know how to enable all this and where to lookup for this entries of course, but I guess for regular users it would be easier to enable various virt. features if they are gathered in one place) Cyrill -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
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. This would simplify not only the configuration process but also Kconfig-related build failures since for your configuration you'll make sure that required stuff is selected. What I'm saying is that not only distro-specific configs but also some sort of hierarchical config options could be defined to automatically preselect stuff for a specific aspect and save a lot of time when configuring a new system. Our config options have grown humongous right about now and we can use the simplification. Of course, you can always do fine-grained tuning afterwards but it'll save a lot of time, in general. Let's have an example: when I have to build upstream on a distro here, I take the distro config and use it despite that it takes a long time to build since everything is module - it is still better for me to wait that one time instead of doing a dozen of trial and errors after forgetting a config option each time. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
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). Cyrill -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond wrote: > We could at least make selection of a minimal set of drivers for the > more common virtualised platforms a lot easier. > Right now, you need to hunt through 30+ different menus in order to find > what you need to run in a basic KVM virtual machine... Yes, every time I build a kernel to be used on KVM I forget something. :-\ We could introduce a section in Kconfig which contains selections for common use cases. E.g. as Linus requested for minimal distro requirements but also selections for various common guest configurations. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
On Fri, Jul 13, 2012 at 10:54 PM, Myklebust, Trond trond.mykleb...@netapp.com wrote: We could at least make selection of a minimal set of drivers for the more common virtualised platforms a lot easier. Right now, you need to hunt through 30+ different menus in order to find what you need to run in a basic KVM virtual machine... Yes, every time I build a kernel to be used on KVM I forget something. :-\ We could introduce a section in Kconfig which contains selections for common use cases. E.g. as Linus requested for minimal distro requirements but also selections for various common guest configurations. -- Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
