From: viro@parcelfarce.linux.theplanet.co.uk
To: Linus Torvalds <torvalds@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: [RFC] removal of legacy cdrom drivers (Re: [PATCH] mcdx.c insanity removal)
Date: Mon, 3 May 2004 02:16:29 +0100 [thread overview]
Message-ID: <20040503011629.GY17014@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.58.0405011953140.18014@ppc970.osdl.org>
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.
next parent reply other threads:[~2004-05-03 1:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040502024637.GV17014@parcelfarce.linux.theplanet.co.uk>
[not found] ` <Pine.LNX.4.58.0405011953140.18014@ppc970.osdl.org>
2004-05-03 1:16 ` viro [this message]
2004-05-03 3:21 ` Rene Herman
2004-05-03 5:59 ` viro
2004-05-03 18:08 ` Rene Herman
2004-05-03 19:45 ` viro
2004-05-03 21:22 ` Rene Herman
2004-05-03 21:30 ` Linus Torvalds
2004-05-03 21:34 ` viro
2004-05-05 23:41 ` Adrian Bunk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040503011629.GY17014@parcelfarce.linux.theplanet.co.uk \
--to=viro@parcelfarce.linux.theplanet.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®