From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
xen-devel@lists.xenproject.org,
James Bottomley <James.Bottomley@suse.de>,
Donald D Dugger <donald.d.dugger@intel.com>,
Pawel Baldysiak <pawel.baldysiak@intel.com>,
Lukasz Dorau <lukasz.dorau@intel.com>,
Artur Paszkiewicz <artur.paszkiewicz@intel.com>,
Ian Campbell <ian.campbell@citrix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
David Vrabel <david.vrabel@citrix.com>
Subject: Re: [PATCH] [SCSI] libsas: Kconfig: Enable SATA compatibility by default
Date: Wed, 06 May 2015 07:23:30 -0700 [thread overview]
Message-ID: <1430922210.2173.157.camel@HansenPartnership.com> (raw)
In-Reply-To: <1430490978-1091-1-git-send-email-ian.jackson@eu.citrix.com>
On Fri, 2015-05-01 at 15:36 +0100, Ian Jackson wrote:
> SATA controllers support SATA disks. The kernel should be able to
> drive these, by default. It should not silently (apart from a
> debugging-only printk) ignore them.
To be honest, this is a bit pointless: no distribution takes the kernel
defaults anyway so changing it achieves nothing.
The original thought behind doing this is that libata was huge and is
pulled in by the sata code whether its actually used or not. Certain
configurations might not want this. However, I think we can all agree
that the major SAS user is enterprise and for them, kernel size isn't
usually a huge worry. Even for enterprise, the predominant
configuration seems to be SAS expanders with SATA drives, so they can't
turn it off anyway. Therefore a more useful question might be: is it
time to remove the option entirely?
James
prev parent reply other threads:[~2015-05-06 14:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <21826.14993.432271.52216@mariner.uk.xensource.com>
2015-05-01 14:36 ` [PATCH] [SCSI] libsas: Kconfig: Enable SATA compatibility by default Ian Jackson
2015-05-03 13:07 ` Julian Calaby
2015-05-06 14:03 ` Ian Jackson
2015-05-06 14:23 ` James Bottomley [this message]
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=1430922210.2173.157.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=James.Bottomley@suse.de \
--cc=artur.paszkiewicz@intel.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=donald.d.dugger@intel.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lukasz.dorau@intel.com \
--cc=pawel.baldysiak@intel.com \
--cc=xen-devel@lists.xenproject.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