simple ide-tape.c and ide-floppy.c cleanup

simple ide-tape.c and ide-floppy.c cleanup

Post by Eduard Bloc » Fri, 05 Jul 2002 01:00:10



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 Stck in Software umgesetzte Schei?e ber-
haupt mieser machen kann, als es sowieso schon ist. Das drfte 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

simple ide-tape.c and ide-floppy.c cleanup

Post by Bartlomiej Zolnierkiewic » Fri, 05 Jul 2002 03:10:07



> 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

simple ide-tape.c and ide-floppy.c cleanup

Post by Pete Zaitce » Fri, 05 Jul 2002 05:20:09


Quote:>[...]
> 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

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

simple ide-tape.c and ide-floppy.c cleanup

Post by Andre Hedric » Fri, 05 Jul 2002 07:20:05


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,


> >[...]
> > 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

> 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

simple ide-tape.c and ide-floppy.c cleanup

Post by James Bottomle » Fri, 05 Jul 2002 07:30:09


Quote:> >[...]
> > 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

simple ide-tape.c and ide-floppy.c cleanup

Post by Martin Daleck » Tue, 09 Jul 2002 13:30:07


U?ytkownik Eduard Bloch napisa3:

Quote:> 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.

Quote:

> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

simple ide-tape.c and ide-floppy.c cleanup

Post by Paul Bristo » Wed, 10 Jul 2002 05:40:09


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...  


>U?ytkownik Eduard Bloch napisa3:

>>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?

Quote:>>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.

Quote:>>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

Web:    http://paulbristow.net
ICQ:    11965223

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

simple ide-tape.c and ide-floppy.c cleanup

Post by Andre Hedric » Wed, 10 Jul 2002 06:50:09


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


> 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...  


> >U?ytkownik Eduard Bloch napisa3:

> >>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

> Web:       http://paulbristow.net
> ICQ:       11965223

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

simple ide-tape.c and ide-floppy.c cleanup

Post by Bartlomiej Zolnierkiewic » Wed, 10 Jul 2002 07:00:12



> 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.


> >U?ytkownik Eduard Bloch napisa3:

> >>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?

Quote:

> 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...

Quote:> >>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

> Web:       http://paulbristow.net
> ICQ:       11965223

Greets
--
Bartlomiej

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

simple ide-tape.c and ide-floppy.c cleanup

Post by Martin Daleck » Wed, 10 Jul 2002 21:30:13


U?ytkownik Paul Bristow napisa3:

> 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...

>> U?ytkownik Eduard Bloch napisa3:

>>> 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. S*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.

Quote:

> 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

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

simple ide-tape.c and ide-floppy.c cleanup

Post by Bartlomiej Zolnierkiewic » Wed, 10 Jul 2002 22:00:08



> U?ytkownik Paul Bristow napisa3:
> > 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...

> >> U?ytkownik Eduard Bloch napisa3:

> >>> 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. S*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?

- Show quoted text -

> > 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

> More majordomo info at  http://www.veryComputer.com/
> Please read the FAQ at  http://www.veryComputer.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/
 
 
 

1. simple ide-tape.c and ide-floppy.c cleanup

Looks pretty good in general, just one minor detail:

[snip]

We already have the "full" list in cdrom.h (GPCMD_*), so lets just use
that. After all, ATAPI_MODE_SELECT10_CMD _is_ the same as the SCSI
variant (and I think the _CMD post fixing is silly, anyone familiar with
this is going to know what ATAPI_WRITE10 means just fine)

Same for request_sense, that is already generalized in cdrom.h as well.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Certified Solaris Administrator

3. simple ide-tape/floppy.c cleanup

4. Problem trying to install uod426b Y2K patch with Custom

5. floppy.c vs. ide-floppy.c

6. Xvnc on Solaris 7 keeps asking session passwd

7. e-ide driver 6.30 uses same interrupt on IDE-0 and IDE-1

8. VIDEO IMAGE CAPTURE/DISPLAY

9. IDE status errors (IDE/SCSI conflict or buggy ide driver?)

10. 2.2.18 IDE tape problem, with ide-scsi