Re: [PATCH] scsi: make scsi_devinfo infrastructure optional

[Bartlomiej Zolnierkiewicz]

On Thu, Feb 10, 2011 at 4:07 PM, James Bottomley
<James.Bottomley@xxxxxxx> wrote:
> On Thu, 2011-02-10 at 10:18 +0100, Bartlomiej Zolnierkiewicz wrote:
>> On Wed, Feb 9, 2011 at 7:00 PM, James Bottomley <James.Bottomley@xxxxxxx> 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?

According to my knowledge all ATAPI quirks are handled locally in libata & sr.

> Most embedded setups include some form of USB ... again, the pluggable
> CD/DVD use the quirks table.

This was done long time ago specifically for embedded 486-like
embedded system w/o USB support and only using flash storage but
indeed this is not a common case.

> Given the potential for disaster even on embedded systems, I don't
> really think something like this is a good idea.

Well, I don't insist on applying it upstream as it is, it is more to
show the direction where the possible room for improvements is in case
of older/embedded systems and reducing memory/code size usage.  [
There were some concerns about it during recent proposal to use more
generalized code for support of some rare Intel-like PATA chipsets
(which seem to cost ~20k as measured on x86-64 in terms of additional
memory/code requirements, though most such systems are x86-32 only so
the incurred cost is probably smaller) .]

BTW with some effort we can do on-demand quirk table loading if it
ever grows too big in the future.

Thanks,
Bartlomiej
--
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/