>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
would like to see disks, and removeable media having a single unified
namespace and set of ioctls so that the different user-space programs
don't need to worry about if they are dealing with a SCSI, PPA,
ATAPI-ish, USB, 1394 or whatever comes next drive. Is that work? yes,
but it's also about communication and keeping things in the appropriate
place. Let me hide the horrible things ide-floppy has to do from
user-space, and if that means I/we have to completely re-write the
ioctls etc so be it.
--Paul
/* ide-floppy maintainer */
Email: paul@paulbristow.net Web: http://paulbristow.net ICQ: 11965223
- 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/