On Tue, May 18, 2010 at 7:54 AM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote: > On 18 May 2010 14:26, Jon Smirl <jonsmirl@xxxxxxxxx> wrote: >> On Tue, May 18, 2010 at 2:03 AM, <david@xxxxxxx> wrote: >>> There are two modes people can be in when configuring a kernel. >>> >>> 1. I want to configure a kernel to support my hardware, enable anything else >>> needed to make it work. >>> >>> 2. I really care about having a small kernel, don't enable anything I have >>> disabled (but help me figure out why something I want isn't available) >>> >>> I don't think that hiding hardware from the user is ever the best thing to >>> do. for approach #1 you obviously don't want to hide anything, but even for >>> approach #2, someone may not realize that by disabling one option they are >>> making it impossible to support something, and as someone who spent a bunch >>> of time hunting through config to find options that I ended up finding were >>> not available without enabling something else, I much prefer to see the >>> option, but see it disabled rather than not being sure if it should be >>> there, or somewhere else in the config. >> >> I have to agree with this. An example is audio drivers that disappear >> because something like SPI is turned off. Sometimes I have to read the >> Kconfig files to figure out what subsystems I need enabled in order to >> make the driver appear as a choice. >> >> Another way this could work... >> Enable the platform >> this causes all subsystems on the platform (usb, spi, pci, etc) to be >> soft enabled >> user selects device drivers or hard enables the subsystem >> on save, if the subsystem wasn't hard enabled for some reason or >> dependency, disable it. >> >> --------------- >> >> I'd also find it useful if Kconfig had an option that analyzed the >> system it is running on and then generated the minimal set of drivers >> needed to support it. Assume that the system is running something like >> the Ubuntu kernel with every driver enabled. Then figure out the >> minimal build footprint for a custom kernel to support the same >> hardware. I do this by hand, but a button for doing it would be a lot >> easier. > > Consider this a response to both of the above e-mails. Just to clear > any confusion, a consequence of using SAT for kconfig is that you can > now say for example only the following: "I want drivers A, B, and C. I > don't care if that means I can't use FOO and I don't care if that > means that I have to use BAR, just give me A, B, and C." > > I suppose another way to see it is that configuring the kernel using > the current menuconfig is a top-down process, since you have to select > USB before you can select any driver that depends on USB. Using SAT > for kconfig puts this on its head, and the configuration process > becomes bottom-up; you say only what you want to have (or not have), > and the system figures out the rest. If you choose a driver that > requires USB (and you haven't said that you also don't want USB > support, which would be impossible), then USB _will_ be enabled > automatically. > > For the record, I think that there are already scripts that take a > running system and builds a config for that. At least some of what you want is provided by 'make localmodconfig' -Kevin Granade > > > Vegard > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
