Re: IDE/ATAPI in 2.5

[Martin Dalecki <dalecki@evision-ventures.com>]

Użytkownik Paul Bristow napisał:
> 
> 
> Martin Dalecki wrote:
> 
>> Workarouns in ide-floppy - ZIP drives and Clock drives.
>>
>> Those are the main "technical issues" which make one hessitate.
>>  
>>
> Sorry, late to this thread.  Look, ide-floppy has to deal with real 
> world devices, which simply don't follow nice, written specifications. 
> If we treat these devices as standard ATAPI they simply don't work.
> 
> And a bunch of planned features which were waiting for 2.5 but are now 
> in limbo until the IDE subsystem is stable enough for me to work on. 
> Features include:
> 
> Trying again to kill the via chipset/Zip interaction (some people are 
> still suffering).
> 
> Kevin Flemings media detect work: needs ATA commands because the ATAPI 
> command set simply doesn't return the information we need.  Then we can 
> make ide-floppy drives work *properly* with devfs.
> 
> Handling the "special" BIOS settings around LS-120/240/Zip bootable 
> drives. 
> Making sure that formatting works properly for non-standard format 
> capacities (i.e. 1.44MB in LS-120, 32MB in LS-240)
> 
> And yes, I have real users asking for these things.
> 
> So to me the problem is not to make everything work as SCSI, because 
> that simply isn't true for ide-floppy devices.  They *nearly* work, so 
> you can get kludgy, "good enough for command line gurus" working with 
> ide-scsi, but there are some funnies.  Does it really make sense to have 
> IDE/ATAPI kludges down in the SCSI tree?
> 
> I much prefer Linus's suggestion of agreeing on the top level API.  I 

Just to make things clear. Personally I by no way think
that ide-scsi should remain an SCSI device. My concern is only the
fact that it would be easier in my opinnion to start off with
ide-scsi and make it *independant* from the SCSI code or device handling
by separating commonly used code for MMC_ handling out of SCSI
in a kind of library (that is it) and not a common "layer"
(this could be a second step).

However this can be accomplished the other way around as well.
It will be just considerable more work.