Re: IDE/ATAPI in 2.5

Martin Dalecki (dalecki@evision-ventures.com)
Sun, 14 Jul 2002 16:04:31 +0200


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.

-
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/