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
--
<[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]>
On 11 Jul 2002, H. Peter Anvin wrote:
> 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.
Already discussed/planned.
Also it has to be done with care on evolution, not revolution way.
Regards
--
Bartlomiej
> 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]>
> 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
On Fri, 12 Jul 2002, Alan Cox wrote:
> > 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.
It was deleted, LOL.
What you really need another NEW maintainer or any other replacement.
> 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
>
>
> -
> 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
On Thu Jul 11, 2002 at 05:27:11PM -0700, H. Peter Anvin wrote:
> 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--
Erik Andersen wrote:
> On Thu Jul 11, 2002 at 05:27:11PM -0700, H. Peter Anvin wrote:
>
>>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,
>
Lovely. Let's make EACH APPLICATION support two disjoint APIs for no
good reason.
Got any other brilliant ideas?
-hpa
On Thu Jul 11, 2002 at 09:17:35PM -0700, H. Peter Anvin wrote:
> Erik Andersen wrote:
> >On Thu Jul 11, 2002 at 05:27:11PM -0700, H. Peter Anvin wrote:
> >
> >>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,
> >
>
> 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--
Erik Andersen wrote:
>>
>>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.
>
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
Followup to: <[email protected]>
By author: Alan Cox <[email protected]>
In newsgroup: linux.dev.kernel
>
> > 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
--
<[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]>
On Thu, 11 Jul 2002, H. Peter Anvin wrote:
> Erik Andersen wrote:
> >>
> >>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.
> >
>
> 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
Andre Hedrick wrote:
>
> 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.
>
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
U?ytkownik H. Peter Anvin napisa?:
> 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.
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,
On Fri, 12 Jul 2002, Martin Dalecki wrote:
> Against:
>
> 1. Bartlomiej Zolnierkiewcz.
What's your reason to vote against him? Something personal?
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------
> 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..
> Against:
> 1. Bart=B3omiej =AFo=B3nierkiewcz.
>
against..
Alan
> > 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..
>
> > Against:
> > 1. Bart=B3omiej =AFo=B3nierkiewcz.
> >
>
> against..
Very well put.
By the way, where's the promised IDE 98?
T.
> 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
> > 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..
> >
> > > 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.
On Fri, 12 Jul 2002, Thunder from the hill wrote:
> Hi,
>
> On Fri, 12 Jul 2002, Martin Dalecki wrote:
> > 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
> 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/
>
U?ytkownik Bartlomiej Zolnierkiewicz napisa?:
> On Fri, 12 Jul 2002, Thunder from the hill wrote:
>
>
>>Hi,
>>
>>On Fri, 12 Jul 2002, Martin Dalecki wrote:
>>
>>>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
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.
On Fri, Jul 12 2002, Martin Dalecki wrote:
> Workarounds in ide-cd - none.
you must be kidding?
--
Jens Axboe
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?
H. Peter Anvin wrote:
> 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
>
U?ytkownik Jens Axboe napisa?:
> On Fri, Jul 12 2002, Martin Dalecki wrote:
>
>>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...
On Fri, Jul 12 2002, Martin Dalecki wrote:
> U?ytkownik Jens Axboe napisa?:
> >On Fri, Jul 12 2002, Martin Dalecki wrote:
> >
> >>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);
> }
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.
> 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 :/
--
Jens Axboe
> Workarounds in ide-cd - none.
There are a few IDE cd ones too. Not too many thankfully
U?ytkownik Kevin P. Fleming napisa?:
> 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 */
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.
On Fri, 12 Jul 2002, Thunder from the hill wrote:
> Hi,
>
> On Fri, 12 Jul 2002, Martin Dalecki wrote:
> > Against:
> >
> > 1. Bartlomiej Zolnierkiewcz.
>
> What's your reason to vote against him? Something personal?
>
> 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/
>
Andre Hedrick
LAD Storage Consulting Group
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
On Fri, 12 Jul 2002, Tomas Szepe wrote:
> > > 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..
> >
> > > 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/
>
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
On Fri, 12 Jul 2002, Jens Axboe wrote:
> On Fri, Jul 12 2002, Martin Dalecki wrote:
> > Workarounds in ide-cd - none.
>
> you must be kidding?
>
> --
> 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/
>
On Fri, 12 Jul 2002, Kevin P. Fleming wrote:
> 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
On Fri, 12 Jul 2002, Martin Dalecki wrote:
>
> 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
Linus Torvalds wrote:
>
> On Fri, 12 Jul 2002, Martin Dalecki wrote:
>
>>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.
>
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
At 19:33 12/07/02, H. Peter Anvin wrote:
>Linus Torvalds wrote:
>>On Fri, 12 Jul 2002, Martin Dalecki wrote:
>>
>>>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.
>
>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
--
"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/
Anton Altaparmakov wrote:
>>
>> 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
On Fri, 12 Jul 2002, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> >
> > On Fri, 12 Jul 2002, Martin Dalecki wrote:
> >
> >>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.
>
> 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).
> 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? ;-)
> 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
>
> -hpa
On Fri, 12 Jul 2002, Anton Altaparmakov wrote:
> 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?
--
function.linuxpower.ca
On Fri, 12 Jul 2002, Linus Torvalds wrote:
> 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.
--
Matthias Andree
"H. Peter Anvin" <[email protected]> writes:
> Andre Hedrick wrote:
> > 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.
> >
>
> 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