From: Jeff Garzik <jgarzik@pobox.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
davej@redhat.com
Subject: Re: [PATCH] libata: fix broken Kconfig setup
Date: Mon, 17 Oct 2005 12:21:18 -0400 [thread overview]
Message-ID: <4353CF7E.1090404@pobox.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0510170848180.23590@g5.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 17 Oct 2005, Jeff Garzik wrote:
>
>>CONFIG_SCSI_SATA does two things:
>>* Enables/disables the display of the SATA driver menu.
>>* Enables/disables the compiled-in PCI quirk.
>>
>>Both of these are boolean, and have absolutely nothing to do with modules.
>
>
> You ignore the biggest thing it does:
> - it is the depends-on for the actual low-level drivers
That dependency for each driver exists solely for menu display purposes.
There is no code dependency.
> IOW, the _biggest_ reason for it existing at all is in fact _not_ a
> boolean. It very much is a tristate. When it's "m" the SATA driver menu
> _should_ show.
The only operational difference between CONFIG_SCSI_SATA=y and
CONFIG_SCSI_SATA=m is that CONFIG_SCSI_SATA=m restricts the drivers from
being compiled in -- a silly and needless restriction.
The elimination of 'y' as an option should propagate from CONFIG_SCSI.
> Also, as already mentioned, that compiled-in PCI quirk is _wrong_. The
> fact that somebody asked for SCSI_SATA should not change Intel settings.
> Maybe somebody hass a separate SATA card, and has enabled support for
> _that_, but wants the on-board thing to work with legacy drivers? The way
> he'd have done that is to enable SCSI_SATA, but _not_ enable
> SCSI_ATA_PIIX.
Agreed this is a _theoretical_ problem.
Never heard of this being an issue in the real world, because the IDE
driver locks up on a lot of the Intel hardware in question. That was
one of the original reason for the split PATA/SATA driver configuration,
for this wonky combined mode.
> Btw, if you want to really hide things (and not just gray them out) I
> think you should do a
>
> menu "SATA low-level drivers"
> depends on SCSI_SATA != n
>
> ..
>
> endmenu
>
> around the SATA drivers.
No preference whether its hidden or greyed out.
CONFIG_SCSI_SATA is just a switch to enable listing a set of drivers,
just like CONFIG_NET_PCI (which I note is a bool), CONFIG_NET_ISA (a
bool), ...
>>Because it's fundamental a boolean, and has -zero- to do with modules.
>>Encouraging people to think otherwise will just lead to more confusion.
>
>
> I disagree. It is no more fundamentally boolean than anything else that
> controls modules. It's a tristate, because it chooses between the
> low-level drivers being tristate.
>
> I also think that the _only_ thing your ugly patch fixes was totally wrong
> for wholly other reasons anyway. If that quirk is needed, it really looks
> like it should be
>
> #if defined(CONFIG_SCSI_SATA_PIIX) || defined(CONFIG_SCSI_SATA_PIIX_MODULE)
> ..
> #endif
If IDE is compiled in, IDE SATA option is not enabled, and ata_piix or
ahci are used.
Do we really want to do
#if defined (CONFIG_IDE_GENERIC) &&
!defined(CONFIG_IDE_BLK_DEV_SATA) &&
(
defined(CONFIG_SCSI_SATA_PIIX) ||
defined(CONFIG_SCSI_SATA_PIIX_MODULE) ||
defined(CONFIG_SCSI_SATA_AHCI ||
defined(CONFIG_SCSI_SATA_AHCI_MODULE)
)
?
At that point it seems easier to solve at the Kconfig level, perhaps
defining CONFIG_SATA_INTEL_COMBINED at the end. And then with the quirk
issue out of the way, CONFIG_SCSI_SATA becomes purely a boolean
enable/disable-this-menu switch.
Jeff
next prev parent reply other threads:[~2005-10-17 16:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-17 4:46 [PATCH] libata: fix broken Kconfig setup Jeff Garzik
2005-10-17 11:10 ` Matthias Urlichs
2005-10-17 11:20 ` Jeff Garzik
2005-10-17 15:14 ` Linus Torvalds
2005-10-17 15:32 ` Jeff Garzik
2005-10-17 15:58 ` Linus Torvalds
2005-10-17 16:21 ` Jeff Garzik [this message]
2005-10-17 16:38 ` Linus Torvalds
2005-10-17 16:53 ` Linus Torvalds
2005-10-17 17:11 ` Jeff Garzik
2005-10-17 17:25 ` Linus Torvalds
2005-10-17 17:38 ` Jeff Garzik
2005-10-19 11:49 ` Alistair John Strachan
2005-10-19 16:02 ` Randy.Dunlap
2005-10-17 17:01 ` Jeff Garzik
2005-10-18 11:15 ` Sergey Vlasov
2005-10-18 20:56 ` Jeff Garzik
2005-10-17 17:12 ` Linus Torvalds
2005-10-17 17:22 ` Jeff Garzik
2005-10-17 16:52 ` Jesse Barnes
2005-10-17 17:03 ` Jeff Garzik
2005-10-17 17:06 ` Jesse Barnes
2005-10-17 17:16 ` Jeff Garzik
2005-10-20 14:14 ` Alan Cox
2005-10-20 16:45 ` Jesse Barnes
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=4353CF7E.1090404@pobox.com \
--to=jgarzik@pobox.com \
--cc=akpm@osdl.org \
--cc=davej@redhat.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.