Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Alain Kalker <miki@dds.nl>]

Op zaterdag 21-03-2009 om 22:11 uur [tijdzone +0100], schreef Alain
Kalker:
> 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@gmail.com> 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.

Also, I believe there are very few (if any) circular, multiple or
conflicting dependencies in the tree.
All this structural information can be used to ease tackling this
problem.

> 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.

> Kind regards,
> 
> Alain