Why not another way round? Just make the ide-scsi driver be prefered,
and hack ide-scsi a bit to simulate the cdrom and adv.floppy devices
that are expected as /dev/hd* by some user's configuration?
To be honest - why keep ide-[cd,floppy,tape] when they can be almost
completely replaced with ide-scsi? I know about only few cdrom devices
that are broken (== not ATAPI compliant) but can be used with
workarounds in the current ide-cd driver. OTOH many users do already
need ide-scsi to access cd recorders and similar hardware, so they would
benefit much more from having ide-scsi as default than few users of
broken "atapi" drives.
Other operating systems did switch to constitent (scsi-based) way of
accessing all kinds of removable media drivers. Why does Linux have to
keep a kludge, written years ago without having a good concept?
Gruss/Regards,
Eduard.
--
Ich glaube nicht, da? man dieses St?ck in Software umgesetzte Schei?e ?ber-
haupt mieser machen kann, als es sowieso schon ist. Das d?rfte das einzige
Programm sein, das vom Verhalten und seinen Anwendern her schlimmer als XP
auf einem Amiga ist. - Manuel Richardt in ka.talk ueber Outlook Express
On Wed, 3 Jul 2002, Eduard Bloch wrote:
> Why not another way round? Just make the ide-scsi driver be prefered,
> and hack ide-scsi a bit to simulate the cdrom and adv.floppy devices
> that are expected as /dev/hd* by some user's configuration?
>
> To be honest - why keep ide-[cd,floppy,tape] when they can be almost
> completely replaced with ide-scsi? I know about only few cdrom devices
> that are broken (== not ATAPI compliant) but can be used with
> workarounds in the current ide-cd driver. OTOH many users do already
> need ide-scsi to access cd recorders and similar hardware, so they would
> benefit much more from having ide-scsi as default than few users of
> broken "atapi" drives.
THE PLAN is to have generic ATAPI driver and generic packet command
driver (ATAPI and SCSI).
:-)
--
Bartlomiej
>[...]
> 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,
On Wed, 3 Jul 2002, Pete Zaitcev wrote:
> >[...]
> > 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
> -
> 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
> >[...]
> > 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.
Hey, you mean it's suddenly become my problem...?
I think I can clean up the SCSI upper layer drivers so they speak request prep
functions which would translate the request (or ioctl) into the correct SCSI
command and hand it back as a REQ_SPECIAL by 2.6
In order for this type of thing to be acceptable to the IDE subsystem, the
attachment can't be a Scsi_Cmnd structure like it is now. The plans I have to
take a struct request all the way down to a SCSI host adapter and get rid of
Scsi_Cmnd will probably finally make it possible to attach the st driver
directly to an IDE device but this definitely won't make it in time for 2.6.
James
U?ytkownik Eduard Bloch napisa?:
> Why not another way round? Just make the ide-scsi driver be prefered,
> and hack ide-scsi a bit to simulate the cdrom and adv.floppy devices
> that are expected as /dev/hd* by some user's configuration?
This is the intention.
>
> To be honest - why keep ide-[cd,floppy,tape] when they can be almost
> completely replaced with ide-scsi? I know about only few cdrom devices
> that are broken (== not ATAPI compliant) but can be used with
> workarounds in the current ide-cd driver. OTOH many users do already
> need ide-scsi to access cd recorders and similar hardware, so they would
> benefit much more from having ide-scsi as default than few users of
> broken "atapi" drives.
>
> Other operating systems did switch to constitent (scsi-based) way of
> accessing all kinds of removable media drivers. Why does Linux have to
> keep a kludge, written years ago without having a good concept?
>
> Gruss/Regards,
> Eduard.
OK. I kept quiet while the IDE re-write went on so that when it was
over I could fix up ide-floppy and start adding some of the requested
features that were only really possible with the taskfile capabilities.
But I have to jump in with the latest statements from Martin...
Martin Dalecki wrote:
>U?ytkownik Eduard Bloch napisa?:
>
>
>>Why not another way round? Just make the ide-scsi driver be prefered,
>>and hack ide-scsi a bit to simulate the cdrom and adv.floppy devices
>>that are expected as /dev/hd* by some user's configuration?
>>
>>
>
>This is the intention.
>
Since when? I thought Jens was in the process of getting rid of the
ide-scsi kludge with his moves to support cd/dvd writing directly in
ide-cd?
>>to be honest - why keep ide-[cd,floppy,tape] when they can be almost
>>completely replaced with ide-scsi? I know about only few cdrom devices
>>that are broken (== not ATAPI compliant) but can be used with
>>workarounds in the current ide-cd driver. OTOH many users do already
>>need ide-scsi to access cd recorders and similar hardware, so they would
>>benefit much more from having ide-scsi as default than few users of
>>broken "atapi" drives.
>>
>>
OK. I would prefer though to take Linus's comment on board about
unifying the removeable media interfaces. Be they IDE, SCSI, Firewire,
USB, whatever. Let's try to make it something comprehensible for
"normal humans", and don't say "let config scripts sort it out - I deal
with many user help requests from broken configs.
Please don't forget that
a) some of the broken ide devices will still need fixes even if
handled via ide-scsi (and yes, devices on the market today are still
broken today)
b) some features still need IDE commands (not ATAPI) which I hoped we
would have done via taskfile - I guess this is tricky via ide-scsi
c) getting ide-scsi working for PCMCIA devices is an absolute f*****g
nightmare - for this reason alone I would keep ide-floppy
d) many of these devices (LS120/LS240/Zip 100/250 etc) can and need to
boot. I don't even know how to start doing this under ide-scsi in it's
present form.
The current system may be ugly, but if we have to break it in the name
of progress we have at least to make the new, improved version work as
well (and hopefully better) than the old one.
>>Other operating systems did switch to constitent (scsi-based) way of
>>accessing all kinds of removable media drivers. Why does Linux have to
>>keep a kludge, written years ago without having a good concept?
>>
>>
>>
If we can address all these issues I will be extremely happy to helping
create a sensible removeable media subsystem.
--
Paul
Linux ide-floppy maintainer
Email: [email protected]
Web: http://paulbristow.net
ICQ: 11965223
Paul,
You have to remember that all that is good is SCSI, that is why the
hardare is dying and going away for the most part. We all know that
ATA/IDE is a thing of the past as is anything with a parallel ribbon.
Just let them go about their merry way as there is something else on the
horizon where your talents would be used if you were willing.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Mon, 8 Jul 2002, Paul Bristow wrote:
> OK. I kept quiet while the IDE re-write went on so that when it was
> over I could fix up ide-floppy and start adding some of the requested
> features that were only really possible with the taskfile capabilities.
> But I have to jump in with the latest statements from Martin...
>
> Martin Dalecki wrote:
>
> >U?ytkownik Eduard Bloch napisa?:
> >
> >
> >>Why not another way round? Just make the ide-scsi driver be prefered,
> >>and hack ide-scsi a bit to simulate the cdrom and adv.floppy devices
> >>that are expected as /dev/hd* by some user's configuration?
> >>
> >>
> >
> >This is the intention.
> >
> Since when? I thought Jens was in the process of getting rid of the
> ide-scsi kludge with his moves to support cd/dvd writing directly in
> ide-cd?
>
> >>to be honest - why keep ide-[cd,floppy,tape] when they can be almost
> >>completely replaced with ide-scsi? I know about only few cdrom devices
> >>that are broken (== not ATAPI compliant) but can be used with
> >>workarounds in the current ide-cd driver. OTOH many users do already
> >>need ide-scsi to access cd recorders and similar hardware, so they would
> >>benefit much more from having ide-scsi as default than few users of
> >>broken "atapi" drives.
> >>
> >>
> OK. I would prefer though to take Linus's comment on board about
> unifying the removeable media interfaces. Be they IDE, SCSI, Firewire,
> USB, whatever. Let's try to make it something comprehensible for
> "normal humans", and don't say "let config scripts sort it out - I deal
> with many user help requests from broken configs.
>
> Please don't forget that
> a) some of the broken ide devices will still need fixes even if
> handled via ide-scsi (and yes, devices on the market today are still
> broken today)
> b) some features still need IDE commands (not ATAPI) which I hoped we
> would have done via taskfile - I guess this is tricky via ide-scsi
> c) getting ide-scsi working for PCMCIA devices is an absolute f*****g
> nightmare - for this reason alone I would keep ide-floppy
> d) many of these devices (LS120/LS240/Zip 100/250 etc) can and need to
> boot. I don't even know how to start doing this under ide-scsi in it's
> present form.
>
> The current system may be ugly, but if we have to break it in the name
> of progress we have at least to make the new, improved version work as
> well (and hopefully better) than the old one.
>
> >>Other operating systems did switch to constitent (scsi-based) way of
> >>accessing all kinds of removable media drivers. Why does Linux have to
> >>keep a kludge, written years ago without having a good concept?
> >>
> >>
> >>
> If we can address all these issues I will be extremely happy to helping
> create a sensible removeable media subsystem.
>
>
> --
>
> Paul
>
> Linux ide-floppy maintainer
> Email: [email protected]
> Web: http://paulbristow.net
> ICQ: 11965223
>
>
>
> -
> 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 Mon, 8 Jul 2002, Paul Bristow wrote:
> OK. I kept quiet while the IDE re-write went on so that when it was
> over I could fix up ide-floppy and start adding some of the requested
> features that were only really possible with the taskfile capabilities.
> But I have to jump in with the latest statements from Martin...
Great.
> Martin Dalecki wrote:
>
> >U?ytkownik Eduard Bloch napisa?:
> >
> >>Why not another way round? Just make the ide-scsi driver be prefered,
> >>and hack ide-scsi a bit to simulate the cdrom and adv.floppy devices
> >>that are expected as /dev/hd* by some user's configuration?
> >
> >This is the intention.
Bad intentions?
> >
> Since when? I thought Jens was in the process of getting rid of the
> ide-scsi kludge with his moves to support cd/dvd writing directly in
> ide-cd?
We should have generic packet command interface ATAPI/SCSI,
ide-cd and sr should care only about ATA(PI)/SCSI specifics.
Of course if this is possible...
> >>to be honest - why keep ide-[cd,floppy,tape] when they can be almost
> >>completely replaced with ide-scsi? I know about only few cdrom devices
> >>that are broken (== not ATAPI compliant) but can be used with
> >>workarounds in the current ide-cd driver. OTOH many users do already
> >>need ide-scsi to access cd recorders and similar hardware, so they would
> >>benefit much more from having ide-scsi as default than few users of
> >>broken "atapi" drives.
> >>
> >>
> OK. I would prefer though to take Linus's comment on board about
> unifying the removeable media interfaces. Be they IDE, SCSI, Firewire,
> USB, whatever. Let's try to make it something comprehensible for
> "normal humans", and don't say "let config scripts sort it out - I deal
> with many user help requests from broken configs.
>
> Please don't forget that
> a) some of the broken ide devices will still need fixes even if
> handled via ide-scsi (and yes, devices on the market today are still
> broken today)
> b) some features still need IDE commands (not ATAPI) which I hoped we
> would have done via taskfile - I guess this is tricky via ide-scsi
> c) getting ide-scsi working for PCMCIA devices is an absolute f*****g
> nightmare - for this reason alone I would keep ide-floppy
> d) many of these devices (LS120/LS240/Zip 100/250 etc) can and need to
> boot. I don't even know how to start doing this under ide-scsi in it's
> present form.
>
> The current system may be ugly, but if we have to break it in the name
> of progress we have at least to make the new, improved version work as
> well (and hopefully better) than the old one.
Fully agreed.
> >>Other operating systems did switch to constitent (scsi-based) way of
> >>accessing all kinds of removable media drivers. Why does Linux have to
> >>keep a kludge, written years ago without having a good concept?
> If we can address all these issues I will be extremely happy to helping
> create a sensible removeable media subsystem.
>
> --
>
> Paul
>
> Linux ide-floppy maintainer
> Email: [email protected]
> Web: http://paulbristow.net
> ICQ: 11965223
Greets
--
Bartlomiej
U?ytkownik Paul Bristow napisa?:
> OK. I kept quiet while the IDE re-write went on so that when it was
> over I could fix up ide-floppy and start adding some of the requested
> features that were only really possible with the taskfile capabilities.
> But I have to jump in with the latest statements from Martin...
> Martin Dalecki wrote:
>
>> U?ytkownik Eduard Bloch napisa?:
>>
>>
>>> Why not another way round? Just make the ide-scsi driver be prefered,
>>> and hack ide-scsi a bit to simulate the cdrom and adv.floppy devices
>>> that are expected as /dev/hd* by some user's configuration?
>>>
>>
>>
>> This is the intention.
>>
> Since when? I thought Jens was in the process of getting rid of the
> ide-scsi kludge with his moves to support cd/dvd writing directly in
> ide-cd?
Well code decides. And in reality I have tried the much simpler goal
to unify the ide-floppy ide-tape and ide-cd parts which
should be common. Like for example a simple SCSI multi media command set
preparation library. Admittedly I have failed. Therefore and in
fact of the 2.6 release schedule it's simple not practical to
persue this road further. It makes much more sense to just
1. Scrap the specific atapi drivers.
2. Try to make ide-scsi independant from SCSI subsystem from users view.
3. Replicate some of the workarounds in the previous ide-xxxx drivers.
>
> The current system may be ugly, but if we have to break it in the name
> of progress we have at least to make the new, improved version work as
> well (and hopefully better) than the old one.
>
>>> Other operating systems did switch to constitent (scsi-based) way of
>>> accessing all kinds of removable media drivers. Why does Linux have to
>>> keep a kludge, written years ago without having a good concept?
>>>
>>>
>>
> If we can address all these issues I will be extremely happy to helping
> create a sensible removeable media subsystem.
That's a deal.
On Tue, 9 Jul 2002, Martin Dalecki wrote:
> U?ytkownik Paul Bristow napisa?:
> > OK. I kept quiet while the IDE re-write went on so that when it was
> > over I could fix up ide-floppy and start adding some of the requested
> > features that were only really possible with the taskfile capabilities.
> > But I have to jump in with the latest statements from Martin...
> > Martin Dalecki wrote:
> >
> >> U?ytkownik Eduard Bloch napisa?:
> >>
> >>
> >>> Why not another way round? Just make the ide-scsi driver be prefered,
> >>> and hack ide-scsi a bit to simulate the cdrom and adv.floppy devices
> >>> that are expected as /dev/hd* by some user's configuration?
> >>>
> >>
> >>
> >> This is the intention.
> >>
> > Since when? I thought Jens was in the process of getting rid of the
> > ide-scsi kludge with his moves to support cd/dvd writing directly in
> > ide-cd?
>
> Well code decides. And in reality I have tried the much simpler goal
> to unify the ide-floppy ide-tape and ide-cd parts which
> should be common. Like for example a simple SCSI multi media command set
> preparation library. Admittedly I have failed. Therefore and in
> fact of the 2.6 release schedule it's simple not practical to
> persue this road further. It makes much more sense to just
>
> 1. Scrap the specific atapi drivers.
>
> 2. Try to make ide-scsi independant from SCSI subsystem from users view.
>
> 3. Replicate some of the workarounds in the previous ide-xxxx drivers.
And how will you support i.e. DSC in ide-tape?
> >
> > The current system may be ugly, but if we have to break it in the name
> > of progress we have at least to make the new, improved version work as
> > well (and hopefully better) than the old one.
> >
> >>> Other operating systems did switch to constitent (scsi-based) way of
> >>> accessing all kinds of removable media drivers. Why does Linux have to
> >>> keep a kludge, written years ago without having a good concept?
> >>>
> >>>
> >>
> > If we can address all these issues I will be extremely happy to helping
> > create a sensible removeable media subsystem.
>
> That's a deal.
>
>
>
> -
> 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/
>