Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756376Ab1BJPHm (ORCPT ); Thu, 10 Feb 2011 10:07:42 -0500 Received: from cantor.suse.de ([195.135.220.2]:41893 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751147Ab1BJPHl (ORCPT ); Thu, 10 Feb 2011 10:07:41 -0500 Subject: Re: [PATCH] scsi: make scsi_devinfo infrastructure optional From: James Bottomley To: Bartlomiej Zolnierkiewicz Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: References: <201102091515.16202.bzolnier@gmail.com> <1297274408.3016.29.camel@mulgrave.site> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Feb 2011 09:07:36 -0600 Message-ID: <1297350456.4933.25.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1498 Lines: 35 On Thu, 2011-02-10 at 10:18 +0100, Bartlomiej Zolnierkiewicz wrote: > On Wed, Feb 9, 2011 at 7:00 PM, James Bottomley wrote: > > On Wed, 2011-02-09 at 15:15 +0100, Bartlomiej Zolnierkiewicz wrote: > >> Add SCSI_QUIRKS config option (default y and dependent on EMBEDDED > >> config option) to allow disabling of scsi_devinfo infrastructure. > >> > >> The output code size savings are ~14k for CONFIG_SCSI_QUIRKS=n > >> (as measured on x86-32): > > > > I don't understand the point of this patch ... without the quirks SCSI > > will do the wrong thing on a whole bunch of stuff. The savings look to > > be tiny ... since the SCSI module is habitually a lot larger than your > > figures suggest. > > The patch was originally done for embedded ATA-only setups. Well, if it's for ATA only then the better course would be extracting libata from scsi. It's also a bit misleading to do sizings on x86, because that doesn't imply embedded to me. Aren't there still ATAPI devices that require the quirks? Most embedded setups include some form of USB ... again, the pluggable CD/DVD use the quirks table. Given the potential for disaster even on embedded systems, I don't really think something like this is a good idea. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/