Skip to contentSkip to conversation

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

PATCH In review Eduard Bloch 5 participants 8 messages Jul 3, 2002 – Jul 9, 2002

lore
Share & tools
lore
#0 lore raw

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

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.

Signature · 4 lines
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
#1 lore raw
Quoted 11 lines · Eduard Bloch

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

#2 lore raw
In reply to Eduard Bloch
Quoted 3 lines · Użytkownik Eduard Bloch

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.

Quoted 15 lines

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.

#3 lore raw

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

Quoted 11 lines · Martin Dalecki
Quoted 5 lines · Użytkownik Eduard Bloch

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?

Quoted 9 lines
Quoted 9 lines

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.

Quoted 6 lines
Quoted 6 lines

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.

Signature · 6 lines
Paul

Linux ide-floppy maintainer
Email:	[email protected]
Web:	http://paulbristow.net
ICQ:	11965223
#4 lore raw

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

Quoted 80 lines · Paul Bristow

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

Quoted 11 lines · Martin Dalecki

U¿ytkownik Eduard Bloch napisa³:

Quoted 5 lines

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?

Quoted 9 lines
Quoted 9 lines

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.

Quoted 6 lines
Quoted 6 lines

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.

Signature · 14 lines
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/
#5 lore raw
In reply to Paul Bristow
Quoted 4 lines · Paul Bristow

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.

Quoted 9 lines
Quoted 7 lines · Martin Dalecki
Quoted 3 lines · Użytkownik Eduard Bloch

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?

Quoted 4 lines
Quoted 1 line

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

Quoted 27 lines
Quoted 9 lines
Quoted 9 lines

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.

Quoted 3 lines

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.

Quoted 6 lines
Quoted 3 lines
Quoted 3 lines

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.

Quoted 8 lines

--

Paul

Linux ide-floppy maintainer
Email: [email protected]
Web: http://paulbristow.net
ICQ: 11965223

Greets
--
Bartlomiej

#6 lore raw
In reply to Paul Bristow
Quoted 11 lines · Użytkownik Paul Bristow
Quoted 9 lines · OK. I kept quiet while the IDE re-write went on so that when it was over I…
Quoted 4 lines · Użytkownik Eduard Bloch

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?

Quoted 3 lines
Quoted 2 lines

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.

Quoted 10 lines

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.

Quoted 6 lines
Quoted 5 lines

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.

#7 lore raw
Quoted 29 lines · Martin Dalecki
Quoted 15 lines · Użytkownik Paul Bristow

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

Quoted 9 lines · Martin Dalecki
Quoted 4 lines · Użytkownik Eduard Bloch

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?

Quoted 5 lines
Quoted 2 lines

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

Quoted 5 lines

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?

Quoted 24 lines
Quoted 5 lines

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.

Quoted 8 lines
Quoted 6 lines
Quoted 5 lines

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/