IDE/ATAPI in 2.5
Okay, I have suggested this before, and I haven't quite looked at this in detail, but I would again like to consider the following, especially given the changes in 2.5:
Please consider deprecating or removing ide-floppy/ide-tape/ide-cdrom and treat all ATAPI devices as what they really are -- SCSI over IDE. It is a source of no ending confusion that a Linux system will not write CDs to an IDE CD-writer out of the box, for the simple reason that cdrecord needs access to the generic packet interface, which is only available in the nonstandard ide-scsi configuration.
There really seems to be no decent reason to treat ATAPI devices as anything else. I understand the ide-* drivers contain some workarounds for specific devices, but those really should be moved to their respective SCSI drivers anyway -- after all, manufacturers readily slap IDE or SCSI interfaces on the same devices anyway.
Note that this is specific to ATAPI devices. ATA hard drives are another matter entirely.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 11 lines · H. Peter Anvin
Okay, I have suggested this before, and I haven't quite looked at this in detail, but I would again like to consider the following, especially given the changes in 2.5:
Please consider deprecating or removing ide-floppy/ide-tape/ide-cdrom and treat all ATAPI devices as what they really are -- SCSI over IDE. It is a source of no ending confusion that a Linux system will not write CDs to an IDE CD-writer out of the box, for the simple reason that cdrecord needs access to the generic packet interface, which is only available in the nonstandard ide-scsi configuration.
Quoted 5 lines
There really seems to be no decent reason to treat ATAPI devices as anything else. I understand the ide-* drivers contain some workarounds for specific devices, but those really should be moved to their respective SCSI drivers anyway -- after all, manufacturers readily slap IDE or SCSI interfaces on the same devices anyway.
Already discussed/planned.
Also it has to be done with care on evolution, not revolution way.
Regards
--
Bartlomiej
Quoted 9 lines
Note that this is specific to ATAPI devices. ATA hard drives are another matter entirely.
-hpa
--
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 2 lines
Please consider deprecating or removing ide-floppy/ide-tape/ide-cdrom and treat all ATAPI devices as what they really are -- SCSI over IDE.
They aren't.
o Not all ide cdrom devices are ATAPI capable
o Many ide floppy devices can do ATAPI but get it horribly wrong
o ide-tape is -totally- weird and unrelated to st
Andre did the framework ready to move to a situation where you could open either the ide-scsi or the ide-cdrom name without module reloading mess. You'd need to ask our new 2.5 IDE maintainer to finish that work off.
For disk it gets much easier. Linus has already said he wants a single 'disk' device, which once we get 32bit dev_t will be nice. With that we can finally turn aacraid, megaraid and other 'fake scsi' devices back to raw block devices without breaking compatibility assumptions, and get more throughput.
Alan
Quoted 5 lines · Alan Cox
Quoted 2 lines
Please consider deprecating or removing ide-floppy/ide-tape/ide-cdrom and treat all ATAPI devices as what they really are -- SCSI over IDE.
They aren't.
Quoted 7 lines
o Not all ide cdrom devices are ATAPI capable
o Many ide floppy devices can do ATAPI but get it horribly wrong
o ide-tape is -totally- weird and unrelated to stAndre did the framework ready to move to a situation where you could open either the ide-scsi or the ide-cdrom name without module reloading mess. You'd need to ask our new 2.5 IDE maintainer to finish that work off.
It was deleted, LOL.
What you really need another NEW maintainer or any other replacement.
Quoted 6 lines
For disk it gets much easier. Linus has already said he wants a single 'disk' device, which once we get 32bit
dev_twill be nice. With that we can finally turn aacraid, megaraid and other 'fake scsi' devices back to raw block devices without breaking compatibility assumptions, and get more throughput.
Quoted 9 lines
Alan
-
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
Followup to: <[email protected]> By author: Alan Cox <[email protected]> In newsgroup: linux.dev.kernel
Quoted 10 lines
Quoted 3 lines
Please consider deprecating or removing ide-floppy/ide-tape/ide-cdrom and treat all ATAPI devices as what they really are -- SCSI over IDE.
They aren't.
o Not all ide cdrom devices are ATAPI capable
o Many ide floppy devices can do ATAPI but get it horribly wrong
o ide-tape is -totally- weird and unrelated to st
OK, non-ATAPI devices need not apply, obviously, but the argument still applies for ATAPI devices...
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 10 lines · H. Peter Anvin
Okay, I have suggested this before, and I haven't quite looked at this in detail, but I would again like to consider the following, especially given the changes in 2.5:
Please consider deprecating or removing ide-floppy/ide-tape/ide-cdrom and treat all ATAPI devices as what they really are -- SCSI over IDE. It is a source of no ending confusion that a Linux system will not write CDs to an IDE CD-writer out of the box, for the simple reason that cdrecord needs access to the generic packet interface, which is only available in the nonstandard ide-scsi configuration.
cdrecord should use the CDROM_SEND_PACKET ioctl, then it would work regardless,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Quoted 14 lines · Erik Andersen
Quoted 10 lines · H. Peter Anvin
Okay, I have suggested this before, and I haven't quite looked at this in detail, but I would again like to consider the following, especially given the changes in 2.5:
Please consider deprecating or removing ide-floppy/ide-tape/ide-cdrom and treat all ATAPI devices as what they really are -- SCSI over IDE. It is a source of no ending confusion that a Linux system will not write CDs to an IDE CD-writer out of the box, for the simple reason that cdrecord needs access to the generic packet interface, which is only available in the nonstandard ide-scsi configuration.
Quoted 3 lines
cdrecord should use the
CDROM_SEND_PACKETioctl, then it would work regardless,
Lovely. Let's make EACH APPLICATION support two disjoint APIs for no good reason.
Got any other brilliant ideas?
-hpa
Quoted 15 lines · H. Peter Anvin
Quoted 14 lines · Erik Andersen
Quoted 10 lines · H. Peter Anvin
Okay, I have suggested this before, and I haven't quite looked at this in detail, but I would again like to consider the following, especially given the changes in 2.5:
Please consider deprecating or removing ide-floppy/ide-tape/ide-cdrom and treat all ATAPI devices as what they really are -- SCSI over IDE. It is a source of no ending confusion that a Linux system will not write CDs to an IDE CD-writer out of the box, for the simple reason that cdrecord needs access to the generic packet interface, which is only available in the nonstandard ide-scsi configuration.
Quoted 6 lines
Quoted 3 lines
cdrecord should use the
CDROM_SEND_PACKETioctl, then it would work regardless,Lovely. Let's make EACH APPLICATION support two disjoint APIs for no good reason.
Lovely. Lets rip off a sarcastic answer without spending two seconds to think. Why would anybody need to support two APIs? The existing CDROM_SEND_PACKET ioctl is an ATAPI/SCSI pass through interface, and is sufficient to operate both IDE and SCSI cd writers.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Quoted 7 lines · Erik Andersen
Quoted 2 lines
Lovely. Let's make EACH APPLICATION support two disjoint APIs for no good reason.
Lovely. Lets rip off a sarcastic answer without spending two
seconds to think. Why would anybody need to support two APIs? The existingCDROM_SEND_PACKETioctl is an ATAPI/SCSI pass through interface, and is sufficient to operate both IDE and SCSI cd writers.
That's fine, but it still only supports CD writers. We have a generic packet interface for a good reason -- we should be able to access it regardless of device type.
It's a specific solution to a generic problem.
-hpa
Quoted 12 lines · H. Peter Anvin
Quoted 10 lines · Erik Andersen
Quoted 3 lines
Lovely. Let's make EACH APPLICATION support two disjoint APIs for no good reason.
Lovely. Lets rip off a sarcastic answer without spending two seconds to think. Why would anybody need to support two APIs? The existing
CDROM_SEND_PACKETioctl is an ATAPI/SCSI pass through interface, and is sufficient to operate both IDE and SCSI cd writers.
Quoted 5 lines
That's fine, but it still only supports CD writers. We have a generic packet interface for a good reason -- we should be able to access it regardless of device type.
It's a specific solution to a generic problem.
Nice, so you still have to strip and export to the transport layer.
Please expand on what you are going to talk to packetized and the associated transport protocol restricted to the scope of storage.
Next count all the different personalitys associated with the discrete transport layer.
If you are referring to Jens' pktcdvd interface out of block, it is no more than a bypass of dealing with scsi. It would allow direct access to the physical transport without portions of OS mucking up things as it does now.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Quoted 5 lines · Andre Hedrick
Nice, so you still have to strip and export to the transport layer.
Please expand on what you are going to talk to packetized and the associated transport protocol restricted to the scope of storage.
Quoted 8 lines
Next count all the different personalitys associated with the discrete transport layer.
If you are referring to Jens' pktcdvd interface out of block, it is no more than a bypass of dealing with scsi. It would allow direct access to the physical transport without portions of OS mucking up things as it does now.
I'm talking specifically about ATAPI devices here. As we have already covered, not all ATA devices are ATAPI, but unless I'm completely off the wall, ATAPI is SCSI over IDE, and should be able to be driven as such. The lack of access to that interface using the established interface mechanisms just bites.
-hpa
Quoted 5 lines
I'm talking specifically about ATAPI devices here. As we have already covered, not all ATA devices are ATAPI, but unless I'm completely off the wall, ATAPI is SCSI over IDE, and should be able to be driven as such. The lack of access to that interface using the established interface mechanisms just bites.
If you load ide-scsi they are run as ATAPI, whats the problem ? Just don't do that for very old ide cdroms or for some ide floppies
Quoted 12 lines · H. Peter Anvin
Quoted 10 lines · Andre Hedrick
Nice, so you still have to strip and export to the transport layer. Please expand on what you are going to talk to packetized and the associated transport protocol restricted to the scope of storage.
Next count all the different personalitys associated with the discrete transport layer.
If you are referring to Jens' pktcdvd interface out of block, it is no more than a bypass of dealing with scsi. It would allow direct access to the physical transport without portions of OS mucking up things as it does now.
Quoted 4 lines
I'm talking specifically about ATAPI devices here. As we have already covered, not all ATA devices are ATAPI, but unless I'm completely off the wall, ATAPI is SCSI over IDE, and should be able to be driven as such. The lack of access to that interface using the established interface mechanisms just bites.
ATAPI is SCSI like C is C++. There are strong similarities but they are regulated by different groups, and have slightly different semantics. Last I checked cdrecord already compensates for those differences but they are there.
Eric
Followup to: <[email protected]> By author: [email protected] (Eric W. Biederman) In newsgroup: linux.dev.kernel
Quoted 11 lines
Quoted 5 lines
I'm talking specifically about ATAPI devices here. As we have already covered, not all ATA devices are ATAPI, but unless I'm completely off the wall, ATAPI is SCSI over IDE, and should be able to be driven as such. The lack of access to that interface using the established interface mechanisms just bites.
ATAPI is SCSI like C is C++. There are strong similarities but they are regulated by different groups, and have slightly different semantics. Last I checked cdrecord already compensates for those differences but they are there.
This is a good analogy, and in that general vein don't forget there are considerable differences between different versions of SCSI as well. Just like there are, in many ways, bigger differences between K&R C and C99 than between contemporary C and C++. It should be possible to write code that handles either one, either generically (obviously the best) or with appropriate conditionals.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 11 lines · Użytkownik H. Peter Anvin
Okay, I have suggested this before, and I haven't quite looked at this in detail, but I would again like to consider the following, especially given the changes in 2.5:
Please consider deprecating or removing ide-floppy/ide-tape/ide-cdrom and treat all ATAPI devices as what they really are -- SCSI over IDE. It is a source of no ending confusion that a Linux system will not write CDs to an IDE CD-writer out of the box, for the simple reason that cdrecord needs access to the generic packet interface, which is only available in the nonstandard ide-scsi configuration.
Quoted 8 lines
There really seems to be no decent reason to treat ATAPI devices as anything else. I understand the ide-* drivers contain some workarounds for specific devices, but those really should be moved to their respective SCSI drivers anyway -- after all, manufacturers readily slap IDE or SCSI interfaces on the same devices anyway.
Note that this is specific to ATAPI devices. ATA hard drives are another matter entirely.
Right now the "votes" go like the following:
In favour of the scrap:
1. HPA.
2. Adam J. Richter.
3. Marcin Dalecki (basically due to give up on the idea of gradual unification).
...
Against:
1. Bartłomiej Żołnierkiewcz.
I think we will need a vote from the "great decission maker".
So Linus what's your opinnion please?
Hi,
Quoted 3 lines · Martin Dalecki
Against:
1. Bartlomiej Zolnierkiewcz.
What's your reason to vote against him? Something personal?
Regards, Thunder
Signature · 7 lines
(Use http://www.ebb.org/ungeek if you can't decode) ------BEGIN GEEK CODE BLOCK------ Version: 3.12 GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$ N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G e++++ h* r--- y- ------END GEEK CODE BLOCK------
Quoted 9 lines · Thunder from the hill
Hi,
Quoted 3 lines · Martin Dalecki
Against:
1. Bartlomiej Zolnierkiewcz.
What's your reason to vote against him? Something personal?
I don't vote against him but against stupid changes.
I try not to mess technical issues with personal ones and I have nothing personal to Martin, only technical ;-)
We can't immediately get rid of ide-cd/floppy/tape.c, look through them, then look through ide-scsi.c and sr.c and you will understand why.
(or not :-( )
Regards
--
Bartlomiej
Quoted 17 lines
Regards, Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode) ------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$ N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G e++++ h* r--- y-
------END GEEK CODE BLOCK-------
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/
Quoted 20 lines · Użytkownik Bartlomiej Zolnierkiewicz
Quoted 10 lines · Thunder from the hill
Hi,
Quoted 3 lines · Martin Dalecki
Against:
1. Bartlomiej Zolnierkiewcz.
What's your reason to vote against him? Something personal?
I don't vote against him but against stupid changes.
I try not to mess technical issues with personal ones and I have nothing personal to Martin, only technical ;-)
Quoted 6 lines
We can't immediately get rid of
ide-cd/floppy/tape.c, look through them, then look throughide-scsi.candsr.cand you will understand why.(or not :-( )
Regards
Workarouns in ide-floppy - ZIP drives and Clock drives. Workarounds in ide-cd - none.
Workarounds in ide-tape - hopelessly many.
Those are the main "technical issues" which make one hessitate.
Quoted 1 line · Martin Dalecki
Workarounds in ide-cd - none.
you must be kidding?
Signature · 1 line
Jens Axboe
Quoted 7 lines · Użytkownik Jens Axboe
Quoted 1 line · Martin Dalecki
Workarounds in ide-cd - none.
you must be kidding?
OK OK.
} else if (ireason == 1) {
/* Some drives (ASUS) seem to tell us that status
* info is available. just get it and ignore.
*/
ata_status(drive, 0, 0);
return 0;
} else {
/* Drive wants a command packet, or invalid ireason... */
printk ("%s: cdrom_read_intr: bad interrupt reason %d\n",
drive->name, ireason);
}Long time not enabled one:
#if !STANDARD_ATAPI
/* the Sanyo 3 CD changer uses byte 7 of TEST_UNIT_READY to
switch CDs instead of supporting the LOAD_UNLOAD opcode */
cmd[7] = cdi->sanyo_slot % 3;#endif
But really nothing scary...
Quoted 12 lines · Martin Dalecki
U?ytkownik Jens Axboe napisa?:
Quoted 7 lines · Martin Dalecki
Quoted 2 lines
Workarounds in ide-cd - none.
you must be kidding?
OK OK.
Quoted 11 lines
} else if (ireason == 1) {
/* Some drives (ASUS) seem to tell us that status
* info is available. just get it and ignore.
*/
ata_status(drive, 0, 0);
return 0;
} else {
/* Drive wants a command packet, or invalid ireason... */
printk ("%s: cdrom_read_intr: bad interrupt reason %d\n",
drive->name, ireason);
}There are more, the BCD stuf, etc. I'm just saying there are quite a few work-arounds buried here and there in ide-cd, saying 'none' is a bit simplified.
Quoted 8 lines
Long time not enabled one:
#if !STANDARD_ATAPI /* the Sanyo 3 CD changer uses byte 7 of TEST_UNIT_READY to switch CDs instead of supporting the LOAD_UNLOAD opcode */ cmd[7] = cdi->sanyo_slot % 3;#endif
Not enabled per-default, but possible. Dunno if anyone actually uses it, though. That kind of stuff you only find out when it's too late :/
Signature · 1 line
Jens Axboe
Jens,
Don't bother this is the guy who know everything about SFF-8020 and no atapi device ever hangs busy bit or delays dsc or drq when transfer to buffer is complete.
Come lets all smoke some more CRACK because you are dealing with ventures in vision that is all vertical, just look out for the cliff in front.
Andre Hedrick
LAD Storage Consulting Group
Quoted 14 lines · Jens Axboe
Quoted 1 line · Martin Dalecki
Workarounds in ide-cd - none.
you must be kidding?
Signature · 7 lines
Jens Axboe - 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/
Quoted 1 line
Workarounds in ide-cd - none.
There are a few IDE cd ones too. Not too many thankfully
Quoted 5 lines · Martin Dalecki
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.
Signature · 7 lines
Paul /* ide-floppy maintainer */ Email: [email protected] Web: http://paulbristow.net ICQ: 11965223
Quoted 9 lines
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.
I totally agree, why pick an arbitrary interface, and call it the 'standard', you might as well define your own standard, which suits the needs of supporting all future interfaces, (in the near future, anyway).
John.
Paul, et al,
Quoted 5 lines
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?
If they arn't SCSI, don't treat them like they are.
Quoted 9 lines
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.
Amen to this... It is a very definite need. And if I may add my $0.02 US, a unified IDE/ATA/ATAPI API for Linux will make Linux more likely to take its place on the desktop. As it stands, I have to fiddle with things more than I like to to get my CD-RW to work with both CD-R and Packet Writing.
Matthew D. Pitts.
Quoted 17 lines · Użytkownik Paul Bristow
Quoted 5 lines · Martin Dalecki
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.
Quoted 7 lines
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.
Hi,
Quoted 5 lines
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).
What about some kind of
retval_t mmc_to_hostcmd(host, cmd, ...);response_t response_to_mmc(host, ...);
?
Regards, Thunder
Signature · 7 lines
(Use http://www.ebb.org/ungeek if you can't decode) ------BEGIN GEEK CODE BLOCK------ Version: 3.12 GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$ N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G e++++ h* r--- y- ------END GEEK CODE BLOCK------
Maybe because I showed him the various docs and he knows better. But Please continue to self propagate, eventually it will halt.
Of the four of you, which one has ever successful written a storage driver with old and modern hardware mixed that has worked properly?
Never mind this is a waste of electons.
Quoted 26 lines · Thunder from the hill
Hi,
Quoted 3 lines · Martin Dalecki
Against:
1. Bartlomiej Zolnierkiewcz.
What's your reason to vote against him? Something personal?
Regards, Thunder
Signature · 13 lines
(Use http://www.ebb.org/ungeek if you can't decode) ------BEGIN GEEK CODE BLOCK------ Version: 3.12 GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$ N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G e++++ h* r--- y- ------END GEEK CODE BLOCK------ - 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
Quoted 6 lines
In favour of the scrap:
1. HPA.
2. Adam J. Richter.
3. Marcin Dalecki (basically due to give up on the idea of gradual unification).
In other words nobody who understands IDE is for and everyone who understands you can't actually get rid of ide-floppy, tape, cdrom internal support and knows about IDE is..
Quoted 3 lines
Against:
1. Bart=B3omiej =AFo=B3nierkiewcz.
against..
Alan
Quoted 11 lines
Quoted 6 lines
In favour of the scrap:
1. HPA.
2. Adam J. Richter.
3. Marcin Dalecki (basically due to give up on the idea of gradual unification).In other words nobody who understands IDE is for and everyone who understands you can't actually get rid of ide-floppy, tape, cdrom internal support and knows about IDE is..
Quoted 5 lines
Quoted 3 lines
Against:
1. Bart=B3omiej =AFo=B3nierkiewcz.against..
Very well put.
By the way, where's the promised IDE 98?
T.
Quoted 11 lines
Quoted 9 lines
In other words nobody who understands IDE is for and everyone who understands you can't actually get rid of ide-floppy, tape, cdrom internal support and knows about IDE is..
Quoted 3 lines
Against:
1. Bart=B3omiej =AFo=B3nierkiewcz.against..
Very well put.
Note I completely agree with people that from a user space perspective they shouldn't be jumping through hoops trying to work out what shape of device it is just to use it at all.
http://www.linuxdiskcert.org/LAD-ide24-2.5.25.patch.bz2
This is currently x86 limited and soon will be recored to the modern api that is so desired. It will also maintion 100% backwards compatablity. It will tested and run in various environments and combinations.
Lastly all of you can trust that I will not destroy your data because of an October deadline.
For all of you out there complaining I write crap code, well if you saw the download list of the web logs, without this announcement that in itself would make the following statement.
Bring back the old and lousy, the new and improved is only a shiny sticker.
Since I really have had little success in submission of patches for 2.4, I can play with 2.5. The best part is I can glean from the mess that is good, and make a final solution which shall work.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Quoted 30 lines · Tomas Szepe
Quoted 11 lines
Quoted 6 lines
In favour of the scrap:
1. HPA.
2. Adam J. Richter.
3. Marcin Dalecki (basically due to give up on the idea of gradual unification).In other words nobody who understands IDE is for and everyone who understands you can't actually get rid of ide-floppy, tape, cdrom internal support and knows about IDE is..
Quoted 5 lines
Quoted 3 lines
Against:
1. Bart=B3omiej =AFo=B3nierkiewcz.against..
Very well put.
By the way, where's the promised IDE 98?
T.
-
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/
Quoted 2 lines · Martin Dalecki
So Linus what's your opinnion please?
I will violently oppose anything that implies that the IDE layer uses the SCSI layer normally. No way, Jose. I'm all for scrapping, but the thing that should be scrapped is ide-scsi.
The higher layers already have much of what the SCSI layer does, and the SCSI layer itself is slowly moving in that direction.
Linus
Quoted 6 lines · Linus Torvalds
Quoted 1 line · Martin Dalecki
So Linus what's your opinnion please?
Quoted 7 lines
I will violently oppose anything that implies that the IDE layer uses the SCSI layer normally. No way, Jose. I'm all for scrapping, but the thing that should be scrapped is ide-scsi.
The higher layers already have much of what the SCSI layer does, and the SCSI layer itself is slowly moving in that direction.
Then *please* make a *compatible* interface available to user space. This certainly can be done; the parallel port IDE interface stuff had exactly such an interface (/dev/pg*) -- we could have a /dev/hg* interface presumably. That is an acceptable solution.
Note again that this discussion (and it's a discussion, not a voting session -- technical pros and cons is what applies) apply to ATAPI (SCSI over IDE) only. Alan has already brought up the fact of non-hard disk non-ATAPI devices, and IMO those devices are explicitly out of scope. Maturity of drivers is another, but right now we're suffering through having to deal with multiple drivers for the same hardware, or with user space having to choose different interfaces depending on connection interface, and either which way that's pretty pathetic.
-hpa
Quoted 5 lines · H. Peter Anvin
Quoted 4 lines · Linus Torvalds
Quoted 1 line · Martin Dalecki
So Linus what's your opinnion please?
Quoted 7 lines
Quoted 5 lines
I will violently oppose anything that implies that the IDE layer uses the SCSI layer normally. No way, Jose. I'm all for scrapping, but the thing that should be scrapped is ide-scsi.
The higher layers already have much of what the SCSI layer does, and the SCSI layer itself is slowly moving in that direction.Then *please* make a *compatible* interface available to user space. This certainly can be done; the parallel port IDE interface stuff had exactly such an interface (
/dev/pg*) -- we could have a/dev/hg*interface presumably. That is an acceptable solution.
But Linus is wanting exactly that! As far as I understand, Linus would like a generic interface sitting at the higher layers, and that is used by the ide/atapi/scsi layers. I read this as implying that the user space interface will also be only one. It will talk to the higher layers, the lower layers can then do all the hw specific magic.
Just my 2p.
Best regards,
Anton
Signature · 5 lines
"I've not lost my mind. It's backed up on tape somewhere." - Unknown -- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
Quoted 5 lines · Anton Altaparmakov
Quoted 2 lines
Then *please* make a *compatible* interface available to user space. This certainly can be done; the parallel port IDE interface stuff had exactly such an interface (
/dev/pg*) -- we could have a/dev/hg*interface presumably. That is an acceptable solution.But Linus is wanting exactly that! As far as I understand, Linus would like a generic interface sitting at the higher layers, and that is used by the ide/atapi/scsi layers. I read this as implying that the user space interface will also be only one. It will talk to the higher layers, the lower layers can then do all the hw specific magic.
That's fine with me.
-hpa
Quoted 5 lines · Anton Altaparmakov
But Linus is wanting exactly that! As far as I understand, Linus would like a generic interface sitting at the higher layers, and that is used by the ide/atapi/scsi layers. I read this as implying that the user space interface will also be only one. It will talk to the higher layers, the lower layers can then do all the hw specific magic.
Oh bother! Where does one get the secret Linus decoder ring?
Signature · 1 line
function.linuxpower.ca
Quoted 14 lines · H. Peter Anvin
Quoted 6 lines · Linus Torvalds
Quoted 1 line · Martin Dalecki
So Linus what's your opinnion please?
Quoted 6 lines
I will violently oppose anything that implies that the IDE layer uses the SCSI layer normally. No way, Jose. I'm all for scrapping, but the thing that should be scrapped is ide-scsi.
The higher layers already have much of what the SCSI layer does, and the SCSI layer itself is slowly moving in that direction.
Quoted 8 lines
Then *please* make a *compatible* interface available to user space. This certainly can be done; the parallel port IDE interface stuff had exactly such an interface (
/dev/pg*) -- we could have a/dev/hg*interface presumably. That is an acceptable solution.Note again that this discussion (and it's a discussion, not a voting session -- technical pros and cons is what applies) apply to ATAPI (SCSI over IDE) only. Alan has already brought up the fact of non-hard disk
Please stop calling ATAPI as SCSI over IDE, it is not. It is Packet Interface over ATA (IDE). Some ATAPI/SCSI devices are functionally equivalent because they support the same command set (i.e. MMC).
Quoted 3 lines
non-ATAPI devices, and IMO those devices are explicitly out of scope. Maturity of drivers is another, but right now we're suffering through having to deal with multiple drivers for the same hardware, or with user
Where multiple means two? ;-)
Quoted 2 lines
space having to choose different interfaces depending on connection interface, and either which way that's pretty pathetic.
It is in fact. Generic higher level interface is a solution.
Greets
--
Bartlomiej
Quoted 2 lines
-hpa
Quoted 6 lines · Linus Torvalds
I will violently oppose anything that implies that the IDE layer uses the SCSI layer normally. No way, Jose. I'm all for scrapping, but the thing that should be scrapped is ide-scsi.
The higher layers already have much of what the SCSI layer does, and the SCSI layer itself is slowly moving in that direction.
Oh, and users will violently oppose when you meddle with drivers and any user-space application stops working because of dropping ide-scsi on the floor. I have been using ide-scsi for ages to drive CD-ROM (mostly) and it's not given me headaches. I like being able to access my CD-ROM as /dev/scd0 regardless if it's SCSI or ATAPI, and if any troubles had arrived on hardware no older than 1997, ide-scsi has solved it for me.
Signature · 1 line
Matthias Andree
I have had plans for a while to add Media Status Notification to the ide-floppy driver, so it can do more intelligent media change management. To do so requires ATA (NOT ATAPI) commands to be issued to the drive(s). How would this work if ide-scsi is being used to talk to the drives? Would ide-scsi have to be taught about removable media and Media Status Notification?
Quoted 22 lines · H. Peter Anvin
Okay, I have suggested this before, and I haven't quite looked at this in detail, but I would again like to consider the following, especially given the changes in 2.5:
Please consider deprecating or removing ide-floppy/ide-tape/ide-cdrom and treat all ATAPI devices as what they really are -- SCSI over IDE. It is a source of no ending confusion that a Linux system will not write CDs to an IDE CD-writer out of the box, for the simple reason that cdrecord needs access to the generic packet interface, which is only available in the nonstandard ide-scsi configuration.
There really seems to be no decent reason to treat ATAPI devices as anything else. I understand the ide-* drivers contain some workarounds for specific devices, but those really should be moved to their respective SCSI drivers anyway -- after all, manufacturers readily slap IDE or SCSI interfaces on the same devices anyway.
Note that this is specific to ATAPI devices. ATA hard drives are another matter entirely.
-hpa
Quoted 1 line · Użytkownik Kevin P. Fleming
I have had plans for a while to add Media Status Notification to the ide-floppy driver, so it can do more intelligent media change management. To do so requires ATA (NOT ATAPI) commands to be issued to the drive(s). How would this work if ide-scsi is being used to talk to the drives? Would ide-scsi have to be taught about removable media and Media Status Notification?
You would have to hook it up to the following:
/*
* SCSI command transformation layer
*/
#define IDESCSI_TRANSFORM 0 /* Enable/Disable transformation */
#define IDESCSI_SG_TRANSFORM 1 /* /dev/sg transformation */
Quoted 6 lines · Kevin P. Fleming
I have had plans for a while to add Media Status Notification to the ide-floppy driver, so it can do more intelligent media change management. To do so requires ATA (NOT ATAPI) commands to be issued to the drive(s). How would this work if ide-scsi is being used to talk to the drives? Would ide-scsi have to be taught about removable media and Media Status Notification?
You load up and bloat the SCSI layer the special function to do the taskfile iops, however since the exported ioctl to permit outside the driver to grant access has been deleted, you have to add more bloat in scsi.
The result is having to stagger scsi's queuing layer to deal with overlap protocols that differ enough to cause major headaches. But this is 2.5 so bring out the wrecking balls and give SCSI equal time.
Andre Hedrick
LAD Storage Consulting Group