Re: [PATCH] remove ide-scsi

Sergei Shtylyov
2008-12-06T23:19:03Z

Hello.

Alan Cox wrote:

>> Oh, yes. SCSI emulation is just what Linux embedded world is asking
>> for...
>>
>
> Well ATAPI is SCSI emulation (its a sort of pidgin SCSI admittedly).
>

ATAPI is SCSI transport (with maybe some quirks at SCSI command level
tho, IIRC). ATA is neither thansport nor does it map to SCSI 1:1. The
code for emulating SCSI on ATA only burdens the kernel (and causes user
complaints about changing disk names from /dev/hdx to /dev/sda :-).

> I'm actually seeing two strands of requests (including from embedded)
>
> - CF only small "dumb as president" type driver that is written to be as
> compact as possible and preferably considers IRQs as optional
>

Yes, support for IRQ-less CF is what IDE core lacks. I must note
however that IRQ-less mode looks inherently risky to me because of the
raciness of tbothe the ATA spec and its implimentatin WRT the "interrupt
pending" state. I may be mistaking but someone of T13 experts (Hale
Landis I guess) told me that the devices require that state to be
cleared to proceed with the command, and that's what the fast polling
host is likely to fail at because it doesn't know if rthe device has
actually entered this state when BSY is cleared... Oh well, that's an
old story...

> - Full SATA and NCQ aware platform support.
>

I don't see how SATA/NCQ support is connected to SCSI.

> although the former is growing quieter and it seems the CF formfactor is
>

We're seeing the IRQ-less CF driver submitted for the Octeon SoC
(which employs up to 16 MIPS cores) -- though it's probably needed only
for the development boards... :-)

> just too clunky for embedded nowdays, especially with the horrendously
> complex and pricy connector - and is being eliminated by MMC/SD and
> friends.
>

Oh, don't tell me about that MMC crap. :-)
For some reason they keep wring the card insert and write protect
signals via GPIO, not directly into controller (and it's yet good if
directly into SoC's own GPIO, not an expander) -- which requires the
drivers to call the platform code hooks. :-(

> Alan
>

MBR, Sergei