linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Noah J. Misch" <noah@caltech.edu>
To: Matthew Wilcox <willy@debian.org>
Cc: linux-ia64@linuxia64.org, linux-kernel@vger.kernel.org
Subject: IA64/simulators - Kconfig logic for drivers/*
Date: Sat, 1 Nov 2003 22:41:07 -0800 (PST)	[thread overview]
Message-ID: <Pine.GSO.4.58.0311012038250.20298@sue> (raw)
In-Reply-To: <20031102043402.GF3824@parcelfarce.linux.theplanet.co.uk>

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?


  reply	other threads:[~2003-11-02  6:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-02  0:35 [PATCH][RFC] Clean up Kconfig logic for IA64 ACPI Noah J. Misch
2003-11-02  3:16 ` [ACPI] " Matthew Wilcox
2003-11-02  4:05   ` Noah J. Misch
2003-11-02  4:34     ` Matthew Wilcox
2003-11-02  6:41       ` Noah J. Misch [this message]
2003-11-03 21:55         ` IA64/simulators - Kconfig logic for drivers/* David Mosberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.4.58.0311012038250.20298@sue \
    --to=noah@caltech.edu \
    --cc=linux-ia64@linuxia64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).