On Sun, Jan 16, 2011 at 03:45:35PM -0800, Linus Torvalds wrote: > And now ask yourself, do you really expect some random user to say "I > want to enable SYSFS and CONFIGFS, because I am going to use ocfs2 on > my system"? > > Really? > > Or do you expect a high-quality implementation of a configuration > script to allow the user to just say "I want ocfs2", and then figure > out the dependencies and solve them for you? > > I'd say that the latter case is OBVIOUSLY the quality implementation, > while the former one is just stupid. It's a bit more complicated than that... * nitpick: config option for a driver foo should be seen only after foo got enabled, so that's another case where we need depends on * nitpick 2: some switchable things really shouldn't be selectable, or you'll get users wondering which of the drivers they'd enabled had lead to 32bit kernel on their amd64 boxen ;-) * all nitpicks aside, there ought to be a way to say "no, I _REALLY_ don't want that shit doing #define if(x) <horrible pile of crap> and if it means that I can't have oprofile, so be it". Without chasing tons of select chains to see which FPOS do I need to disable to get rid of the damn thing. Right now the propagation of select chains makes it more and more unpleasant. IOW, it would be very nice to be able to pin a select target down, turning selects leading to it into hard dependencies. Another obviously missing thing is that dependencies should propagate back through select chains. I.e. if A selects B, then hard dependencies of B should append to those of A. It gets really lousy when you have shitloads of drivers spread over several Kconfig menus, all selecting an option that has a hard dependency. As it is, if you want e.g. allmodconfig to produce something that builds you have to chase them all down and add dependencies to each of those drivers. We have such piles in e.g. drivers/media. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
