Re: Please include const-sections into linux-next

[James Bottomley]

On Wed, 2011-10-19 at 18:33 +0200, Andi Kleen wrote:
> > OK, look at it another way: why do we need the type annotations?  I
> > think it's only for section conflict checking, right?  If the compiler
> > gets it wrong anyway, why not just dump all the type annotations, then
> > it should have no type conflicts (spurious or otherwise) to complain
> > about.  We already have link time section checking scripts (they're the
> > useless ones that complain about section mismatches in dev annoations)
> > so why not put them to work to make up for compiler deficiencies?
> 
> You mean removing all the init sections stuff?  I think it has been proposed
> in the past, but it's a couple of hundred KB of memory usually.
> Would you accept that for PA-RISC? 
> 
> If you have init sections you need to annotate them correctly because
> a section is defined by its rwx attributes plus name and both need
> to match. We didn't always check this, so there was some bitrot,
> but it ultimatively has to be correct.

We're talking at cross purposes. But it doesn't matter, the error
doesn't seem to be anything to do with type.  This simple patch is
what's causing it (I can apply it alone to the working tree) and get the
error.

What I can't see is why.

James

---
diff --git a/drivers/net/fealnx.c b/drivers/net/fealnx.c
index fa8677c..196356f 100644
--- a/drivers/net/fealnx.c
+++ b/drivers/net/fealnx.c
@@ -150,7 +150,7 @@ struct chip_info {
 	int flags;
 };
 
-static const struct chip_info skel_netdrv_tbl[] __devinitdata = {
+static const struct chip_info skel_netdrv_tbl[] __devinitconst = {
  	{ "100/10M Ethernet PCI Adapter",	HAS_MII_XCVR },
 	{ "100/10M Ethernet PCI Adapter",	HAS_CHIP_XCVR },
 	{ "1000/100/10M Ethernet PCI Adapter",	HAS_MII_XCVR },


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