[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1259161737.2535.6.camel@mulgrave.site>
Date: Wed, 25 Nov 2009 09:08:57 -0600
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Alan Jenkins <alan-jenkins@...fmail.co.uk>
Cc: Rusty Russell <rusty@...tcorp.com.au>,
Alex Chiang <achiang@...com>, Tony Luck <tony.luck@...il.com>,
Sam Ravnborg <sam@...nborg.org>,
Mike Frysinger <vapier.adi@...il.com>, greg@...ah.com,
linux-kbuild@...r.kernel.org, carmelo73@...il.com,
linux-kernel@...r.kernel.org, kyle@...artin.ca, deller@....de,
jejb@...isc-linux.org,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
paulus@...ba.org
Subject: Re: [PATCH 05/10] kbuild: sort the list of symbols exported by the
kernel (__ksymtab)
On Wed, 2009-11-25 at 09:15 +0000, Alan Jenkins wrote:
> James Bottomley wrote:
> > On Tue, 2009-11-24 at 09:28 +0000, Alan Jenkins wrote:
> >
> >> James Bottomley wrote:
> >>
> >>> On Tue, 2009-11-24 at 11:27 +1030, Rusty Russell wrote:
> >>>
> >>>
> >>>> On Tue, 24 Nov 2009 06:23:20 am Alex Chiang wrote:
> >>>>
> >>>>
> >>>>> Hi Alan, Rusty,
> >>>>>
> >>>>>
> >>>> Hi Alex,
> >>>>
> >>>>
> >>>>
> >>>>> In the meantime, while Alan is deciding the proper way to fix
> >>>>> this, would it be possible to drop the offending patch series
> >>>>> from linux-next?
> >>>>>
> >>>>>
> >>>> Done. That takes the pressure off Alan, and makes sure he has time to get
> >>>> it right.
> >>>>
> >>>>
> >>> That probably suits us on parisc too. I just checked out our build in
> >>> linux-next: we don't pass __modpost ... it looks like we have all the
> >>> module symbols undefined. Will investigate more.
> >>>
> >>> James
> >>>
> >>>
> >> I think parisc wants P'printk where ia64 uses @fptr(printk).
> >>
> >> It may also need ".import printk,code" or similar.
> >>
> >
> > I think if you have to make modpost architecture specific, there's
> > something a bit wrong in the patch series.
> >
> > I can confirm that reverting this particular patch allows the parisc
> > build to work again. It still won't boot because module symbols aren't
> > resolved.
> >
> > James
> >
>
> Yes, the series as a whole relies on that patch. Rusty pulled the
> series from linux-next (thanks rusty!).
Not according to current linux-next:
jejb@ion> git log next-20091125|grep -3 'sort the list of symbols'
Author: Alan Jenkins <alan-jenkins@...fmail.co.uk>
Date: Sat Nov 7 21:03:56 2009 +0000
kbuild: sort the list of symbols exported by the kernel (__ksymtab)
modpost of vmlinux.o now extracts the ksymtab sections and outputs
sorted versions of them as .tmp_exports-asm.S. These sorted sections
Could we please have this removed so we can resume our testing of next?
> I'm working on alternatives now. I can't promise to avoid architecture
> specific code, but if it's necessary then I understand I have to arrange
> to test it myself :-). Sorry for the inconvenience caused by
> "arch-independent assembly code" that wasn't.
I'm not sure I understand what you're trying to do, but it seems to me
that the way to do what you want is to introduce an arch macro for
function pointer which we all define in our headers to be however our
assemblers represent it ... for non fptr arches this would be an
identity.
We don't need there to be no arch changes ... but we do need any arch
specificity confined to arch specific files.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists