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

From: viro
Date: Sun May 02 2004 - 20:18:28 EST


Aiiee...

You know, mcdx.c is like a roadkill - just can't stop looking at the thing.

a) it doesn't initialize when non-modular. Since 2.5.0. Fixed, can send.
b) it leaks on failure exits; since forever. Fixed, can send.
c) it has several lovely bugs (e.g. foo = bar | SINGLE ? ... : ..., where
SINGLE is defined as 1; from the context it's obvious that it should've
been bar & SINGLE; there since 1.3.71). Fixed, can send.
d) it has tons of crimes against decency - e.g.
foo = bar > (foo += baz) ? bar : foo;
where foo, bar and baz and fairly long expressions. Partially fixed, can send.
Oh, and let's not forget the lovely variable names - e.g. "stuffp" through
the entire thing. That's "pointer to all stuff we have about that device".

e) it does *entire* *damn* *IO* without dropping queue lock. And yes, it
*does* block in there. A lot. Always had.

I can fix the last one, however at that point I'm really starting to wonder
if we want to keep the FPOS in the tree. I don't have the hardware and while
I'm reasonably sure that I can split the transition into provably correct
small steps, I doubt that there's any point in doing that. Driver is obviously
not used by anyone and hadn't been used for years.

The same goes for the rest of drivers/cdrom - cdrom.c is used, all right
(ide-cd, sr, pcd), but everything else is
* abandoned by maintainers 5-6 years ago
* broken
* obviously not used by anybody
* impossible to debug due to lack of hardware
* fucking ugly

How about removing all that stuff instead of keeping the known broken shit
in the tree? If somebody wants it back, they can always pick the versions
circa 2.6.0 from archives.

If you are OK with that (and nobody on l-k stands up and claims that they want
it alive and *claims* *that* *right* *fucking* *NOW*) I'll send you a patch
putting these buggers out of their misery.
-
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/