LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
To: Adrian Bunk <bunk@kernel.org>
Cc: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
	rusty@rustcorp.com.au, LKML <linux-kernel@vger.kernel.org>,
	linux-input@vger.kernel.org, Andy Whitcroft <apw@shadowen.org>,
	Balbir Singh <balbir@linux.vnet.ibm.com>
Subject: Re: [BUILD_FAILURE] 2.6.24-git18 build fails section type conflict psmouse-base
Date: Sat, 9 Feb 2008 01:25:44 +0300	[thread overview]
Message-ID: <20080208222544.GA15333@jurassic.park.msu.ru> (raw)
In-Reply-To: <20080208133022.GA2254@cs181133002.pp.htv.fi>

On Fri, Feb 08, 2008 at 03:30:22PM +0200, Adrian Bunk wrote:
> > > On Fri, Feb 08, 2008 at 04:02:59PM +0530, Kamalesh Babulal wrote:
> > >> The 2.6.24-git18 kernel build fails on the power machine with following message
> > >> drivers/input/mouse/psmouse-base.c:44: error: __param_proto causes a section type conflict

My fault - I somehow overlooked that ppc64 is the club member...

> The comment is wrong now, the #if's should refer to kconfig variables, 
> and I don't know whether this patch is really the best solution.

I think it's the best, because it at least points at some of
the problems which arise when you blindly rely on some undocumented
behaviour of __attribute__(section()) on certain platform, and
assume it's the same for the rest of the world...

Alternatives are:
- drop the 'const' qualifier from that macro unconditionally, so that
  __param section gets read/write on all arches. I'd be fine with it,
  but then we'll probably have the same problem again and again...
- make the offending module_param functions global (psmouse and 3-4
  other places). But how do you explain that to driver writers?
  These functions are logically private to this particular module,
  so it's obviously not the same as "we don't export static functions",
  though underlying problem is precisely the same on our three
  platforms...
- hack up gcc. But I don't even have a proposal, because it's not a bug
  from gcc point of view. Ideally, I'd like to pass some extra parameters
  to __attribute__(section()), like r/w control and some equivalent of
  -fno-jump-tables...

Oh, well. Updated patch in a minute.

Ivan.

  parent reply	other threads:[~2008-02-08 22:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-08 10:32 Kamalesh Babulal
2008-02-08 10:48 ` Adrian Bunk
2008-02-08 12:50   ` Kamalesh Babulal
2008-02-08 13:30     ` Adrian Bunk
2008-02-08 14:23       ` Kamalesh Babulal
2008-02-08 22:25       ` Ivan Kokshaysky [this message]
2008-03-03  4:35   ` Rusty Russell
2008-03-03  8:13     ` Adrian Bunk
2008-03-04  2:35       ` Rusty Russell

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=20080208222544.GA15333@jurassic.park.msu.ru \
    --to=ink@jurassic.park.msu.ru \
    --cc=apw@shadowen.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=bunk@kernel.org \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --subject='Re: [BUILD_FAILURE] 2.6.24-git18 build fails section type conflict psmouse-base' \
    /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

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).