Re: [RFC] removal of legacy cdrom drivers (Re: [PATCH] mcdx.c insanity removal)

[viro]

On Mon, May 03, 2004 at 05:21:07AM +0200, Rene Herman wrote:
> I do actually still use two of these drives. An actual soundblaster 
> connected "sbpcd" drive (which sits in a 386, and given the fact that 
> the new init-module-tools didn't compile against libc5 I haven't tested 
> it modular there yet -- builtin it doesn't work) and a "Pro Audio 
> Spectrum" connected "cdu31a" which does work. Most of the time. When the 
> timing is just right, it even allows me to mount cd-roms:

OK...  So we have
	* potentially faulty mcdx (2.4, apparently either driver corrupts
memory in some conditions or isofs does the same for some IO failures -
need to take a look at that report more carefully).
	* cdu31a (FUBAR driver, nasty to fix, "most of the time" works on
2.6)
	* sbpcd (at least two, both untested with 2.6)

> Hope this qualifies a bit. Must say that one of the things I appreciate 
> about Linux is that all this old gunk I have lying about (in fact, still 
> drag in from time to time) is actually supported. Or "supported".
> 
> Would it be good to have a CONFIG_LEGACY alongside CONFIG_EXPERIMENTAL 
> and friends and dump all this crap into drivers/legacy/cdrom, where it 
> wouldn't distract serious people?

	Is anybody willing to fix those drivers?  'Cause I'm _not_ taking
sbpcd.c, thank you very much - I've played with it for a while, but this
sucker is a testing nightmare.  It is a bunch of drivers for different
models mostly ifdefed together.  Take problems with Becker's netdev drivers,
multiply by plenty and add the fact that while Becker definitely knows C,
sbpcd author doesn't.  floppy.c is cleaner than that beast; come to think
of that, so are toilets on most of the bus stations.

	cdu31a, BTW, still uses cli(), schedules under queue lock and uses
timers in very interesting way.  And that's just from the first look...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/