IA64/simulators - Kconfig logic for drivers/*

[Noah J. Misch]

On Sun, 2 Nov 2003, Matthew Wilcox wrote:

> > Why not include drivers/Kconfig and scrap the individual subdirectory
> > includes, as i386 does?
>
> At that time, I hadn't done the work to create drivers/Kconfig ;-)
> The main problem for ia64 is the simulator stuff.  Maybe something like:
>
> if !IA64_HP_SIM
> source "drivers/Kconfig"
> endif
>
> if IA64_HP_SIM
> source "drivers/base/Kconfig"
> source "drivers/scsi/Kconfig"
> source "net/Kconfig"
> source "drivers/block/Kconfig"
> source "arch/ia64/hp/sim/Kconfig"
> endif

I would guess that everyone who uses a simulator is a kernel developer or maybe
an application developer.  I worry that the risk of hiding useful configs from
simulator users by lax maintenance of that block of Kconfig logic exceeds the
risk of those people trying to build a simulator kernel with all kinds of
hardware drivers and finding that it doesn't work.  A quieter configuration is
nice, however.  Hmmm.

What about something like the following - create a new config, ARCH_SIMULATOR,
that IA64_HP_SIM and any other barebones simulators set.  Then put an "if
!ARCH_SIMULATOR" on the subdir includes in drivers/Kconfig that definitely don't
apply to simulators (drivers specifically for real hardware).  That increases
the probability that people who add new features that simulator users might want
will know to unmask them, since far more people see drivers/Kconfig than do
arch/ia64/Kconfig, and it handles similar simulators in a uniform way.

You could also extend that strategy by, for example masking the SCSI low level
drivers menu with an "if !ARCH_SIMULATOR" so simulator users see the generic
SCSI machinery but not all the irrelevant hardware drivers.

What do you think?

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