Re: [PATCH] remove ide-scsi

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

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