lkml.org 
[lkml]   [2009]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 05/10] kbuild: sort the list of symbols exported by the kernel (__ksymtab)
From
Date
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@tuffmail.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




\
 
 \ /
  Last update: 2009-11-25 16:11    [W:0.479 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site