Op donderdag 19-03-2009 om 15:43 uur [tijdzone -0700], schreef Trent Piepho: > On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote: > > On Thu, 19 Mar 2009 17:18:47 +0300 > > Alexey Klimov <klimov.linux@xxxxxxxxx> wrote: > > over what we currently have on our complex Kbuilding system. > > > > For the out-of-system building, one alternative would be to create some make > > syntax for building just some drivers, like: > > > > make driver=cx88,ivtv > > The problem with this is that it's really hard to do decently. It depends on how you define 'decently'. We're not trying to find a general solution to the Boolean Satisfiability Problem here, we can use information about the structure of the dependencies to simplify. As I see it, drivers depend on subsystems, which in turn depend on core functionality. These are mandatory dependencies: an USB device won't function without USB support. Then there are recommended and optional dependencies, which enhance the functionality of a driver. As I have seen with the dummy frontend module, a driver doesn't need to _have_ a frontend module to be functional (e.g. if there simply isn't one written yet), it just will be (much) less useful. Pruning (deselecting) all principal modules (i.e. those that actually provide modaliases) for devices that we don't want, and then pruning all of their dependencies that have now become redundant (i.e. modules that have nothing or only unselected modules depending on them) seems decent enough to me. > For instance, if you want cx88 dvb support, you need some front-ends to do > anything with it. Well, what front-ends should be turned on? You can turn > on any number from none to all. Probably all of them would be best. But > there are tons of other tuners, front-ends, decoders, drivers, etc. that > cx88 doesn't use. Those should be off. This is already covered by DVB_FE_CUSTOMIZE. A user who just wants a driver for his device and doesn't know (or care) what frontend it uses, can just supply a target config of: CONFIG_DVB_FE_CUSTOMISE=n CONFIG_<driver>=m and build the driver, which should simply build all available frontend modules. This already happens with allmodconfig, and as far as I know, the current drivers don't care if one or many frontent modules are available, the right one to use will be selected during hardware probe/attach depending on the actual hardware anyway. A user who wants to further customise the frontend(s) used with the driver, should supply this information: DVB_FE_CUSTOMISE=y CONFIG_<driver>=m CONFIG_<frontend>=M ... This looks very much like the 'virtual packages' and 'alternatives' support in package managers. > So you give an algorithm the config variables you want set (e.g., > VIDEO_CX88) and then tell it to find a valid solution to the rest of the > variables given the constraints from Kconfig. This is the classic > NP-complete SAT problem. It is hard, but we can solve this. By redefining dependencies and restructuring the dependency graph so requirements can be propagated better, you can greatly reduce this problem, to the point that simple search, backtracking or heuristics become quite feasible. Again, package managers are a good example. Entire Linux installers, live cds and preconfigured embedded systems are being generated with very little user intervention on a daily basis. Kind regards, Alain -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
