simple ide-tape.c and ide-floppy.c cleanup
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines
[...]
To be honest - why keep ide-[cd,floppy,tape] when they can be almost completely replaced with ide-scsi?
James Bottomley was going to take care of this, so I did not even bother with ide-tape cleanups in 2.5. Good riddance for that crap.
Note though, ide-tape is not anywhere near semantically
to the ide-scsi+st, because of its "sophisticated" (e.g. utterly broken) internal pipeline. It does a lot of work underneath the /dev boundary. Apparently, the author had a bad case of streaming stoppages on his 386, so instead of fixing the root cause he wrote the monster we have today. Getting rid of ide-tape may cause problems on 386's. But then again, perhaps not.
-- Pete
OIC, then it is clear that SCSI can deal with DSC overlap and granting bandwidth to the other device on the chain which is not ATAPI. Sorry Pete, but this is the typical mind set of people who do not understand all the specification from the past that current hardware is bound to. Gadi was very clever in making DSC work. I understand the principles but seriously doubt I could have derived what Gadi did.
Cheers,
Quoted 16 lines · Pete Zaitcev
Quoted 3 lines
[...]
To be honest - why keep ide-[cd,floppy,tape] when they can be almost completely replaced with ide-scsi?James Bottomley was going to take care of this, so I did not even bother with ide-tape cleanups in 2.5. Good riddance for that crap.
Note though, ide-tape is not anywhere near semantically
to the ide-scsi+st, because of its "sophisticated" (e.g. utterly broken) internal pipeline. It does a lot of work underneath the /dev boundary. Apparently, the author had a bad case of streaming stoppages on his 386, so instead of fixing the root cause he wrote the monster we have today. Getting rid of ide-tape may cause problems on 386's. But then again, perhaps not.
Quoted 7 lines
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andre Hedrick
LAD Storage Consulting Group