LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [software coproarchaeology] sbc8240 story
@ 2008-10-26 18:56 Al Viro
  2008-10-27  6:23 ` David Newall
  2008-10-27 21:26 ` Christian Kujau
  0 siblings, 2 replies; 3+ messages in thread
From: Al Viro @ 2008-10-26 18:56 UTC (permalink / raw)
  To: linux-kernel; +Cc: dwmw2

Where: drivers/mtd/maps/sbc8240.c
What: fucked
When: since before the merge into mainline 4 years ago
How: won't even compile, for starters.

The driver had been added to mtd CVS back in September 2003.  At the time
it had moderate bitrot - it appears to have been written for the mtd tree
as of early May 2003.  The changes needed to fix it had been trivial -
mtd->module got renamed to mtd->owner.  Additionally, it had been ripe
for conversion to simple_map_init().

The sucker had sat there until July 2004, when it got pushed into the
mainline.  Just before the merge the conversion to simple_map_init()
had been done - with a trivial fuckup.  Instead of

                simple_map_init(&sbc8240_map[i]);
                sbc8240_mtd[i] = do_map_probe("jedec_probe", &sbc8240_map[i]);
it did
                simple_map_init(&sbc8240_mtd[i]);
                sbc8240_mtd[i] = do_map_probe("jedec_probe", &sbc8240_map[i]);

Note that this not only makes no sense at all; cc(1) would scream on that,
since simple_map_init() expects a pointer to map_info to be filled, not
a pointer to pointer to mtd_info.  Not that it mattered much, since the
damn thing wouldn't compile anyway - a few lines below we have
                        sbc8240_mtd[i]->module = THIS_MODULE;
and that field had been renamed to 'owner'.

So it had sat in the mainline kernel for 4 years.  During those years _nobody_
had ever tried to compile it.  Nonetheless, there had been patches affecting
it - including such exciting stuff as removal of trailing whitespaces, which
had certainly greatly improved the damn thing.

Frankly, I don't know what the right thing to do with that.  Sure, fixing
this couple of idiocies is trivial and the driver is straightforward enough,
so that's probably all it would take to.  Moreover, it's not as if that
mess had been the original author's fault - the driver definitely used to
work around the time it had been submitted to mtd CVS.

On the other hand...  Trivially fixed or not, we have the absolute proof
that nobody had ever used that driver since its inclusion into the mainline. 
So it's either the patch below or removing the thing completely...

As an aside, this story says a lot about our build coverage.  And probably
quite a few sad things about development process...

diff --git a/drivers/mtd/maps/sbc8240.c b/drivers/mtd/maps/sbc8240.c
index 6e1e99c..236c947 100644
--- a/drivers/mtd/maps/sbc8240.c
+++ b/drivers/mtd/maps/sbc8240.c
@@ -169,12 +169,12 @@ int __init init_sbc8240_mtd (void)
 			}
 			return -EIO;
 		}
-		simple_map_init(&sbc8240_mtd[i]);
+		simple_map_init(&sbc8240_map[i]);
 
 		sbc8240_mtd[i] = do_map_probe("jedec_probe", &sbc8240_map[i]);
 
 		if (sbc8240_mtd[i]) {
-			sbc8240_mtd[i]->module = THIS_MODULE;
+			sbc8240_mtd[i]->owner = THIS_MODULE;
 			devicesfound++;
 		} else {
 			if (sbc8240_map[i].map_priv_1) {

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [software coproarchaeology] sbc8240 story
  2008-10-26 18:56 [software coproarchaeology] sbc8240 story Al Viro
@ 2008-10-27  6:23 ` David Newall
  2008-10-27 21:26 ` Christian Kujau
  1 sibling, 0 replies; 3+ messages in thread
From: David Newall @ 2008-10-27  6:23 UTC (permalink / raw)
  To: Al Viro; +Cc: linux-kernel, dwmw2

Al Viro wrote:
> we have the absolute proof
> that nobody had ever used that driver since its inclusion into the mainline. 

Perhaps it's being used in an old kernel; and eventually they might hope
to upgrade.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [software coproarchaeology] sbc8240 story
  2008-10-26 18:56 [software coproarchaeology] sbc8240 story Al Viro
  2008-10-27  6:23 ` David Newall
@ 2008-10-27 21:26 ` Christian Kujau
  1 sibling, 0 replies; 3+ messages in thread
From: Christian Kujau @ 2008-10-27 21:26 UTC (permalink / raw)
  To: Al Viro; +Cc: LKML, dwmw2

On Sun, 26 Oct 2008, Al Viro wrote:
> As an aside, this story says a lot about our build coverage.  And probably
> quite a few sad things about development process...

For the record: the driver depends on MTD_JEDECPROBE && 8260, where 8260 
is filed under "82xx-based boards" in PowerPC. I don't know if we have 
that much compile tests for this particular arch. http://l4x.org "only" 
lists cell_defconfig and g5_defconfig...

C.
-- 
BOFH excuse #167:

excessive collisions & not enough packet ambulances

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-10-27 21:26 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-26 18:56 [software coproarchaeology] sbc8240 story Al Viro
2008-10-27  6:23 ` David Newall
2008-10-27 21:26 ` Christian Kujau

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).