[PATCH v2 0/5] Eliminate most of sparc_ksyms_*.c

[PATCH v2 0/5] Eliminate most of sparc_ksyms_*.c

[Julian Calaby]

Hi all,

This patch set eliminates most of the definitions within 
arch/sparc/kernel/sparc_ksyms_*.c by moving them to their rightful places.

This is done within patches 1-3.

Note that this work was originally performed by Sam Ravnborg and these 
patches have been rebased and added to by myself.

I've tried to reflect this in the commit messages but may have gotten it 
a little wrong.

Patches 4 and 5 are cleanups that I had in my tree for an eventual 
oplib_*.h unification - but as this screws up my original patches and 
they're so small, I figured this'd be as good a time as any to send them.

Changes in version 2:
1. Patches 2 and 3 have a few more includes added to the modified files.
2. It shouldn't be word wrapped this time!

Thanks,

Julian Calaby

Re: [PATCH v2 0/5] Eliminate most of sparc_ksyms_*.c

[Sam Ravnborg]

On Thu, Jan 08, 2009 at 11:29:58PM +1100, Julian Calaby wrote:
> Hi all,
> 
> This patch set eliminates most of the definitions within 
> arch/sparc/kernel/sparc_ksyms_*.c by moving them to their rightful places.
> 
> This is done within patches 1-3.
> 
> Note that this work was originally performed by Sam Ravnborg and these 
> patches have been rebased and added to by myself.
> 
> I've tried to reflect this in the commit messages but may have gotten it 
> a little wrong.
> 
> Patches 4 and 5 are cleanups that I had in my tree for an eventual 
> oplib_*.h unification - but as this screws up my original patches and 
> they're so small, I figured this'd be as good a time as any to send them.
> 
> Changes in version 2:
> 1. Patches 2 and 3 have a few more includes added to the modified files.
> 2. It shouldn't be word wrapped this time!

Hi Julian.

I have tested your patches by applying them one-by-one
and done both sparc and sparc64 builds.

Everything worked as expected - good work!

	Sam

Re: [PATCH v2 0/5] Eliminate most of sparc_ksyms_*.c

[Sam Ravnborg]

On Thu, Jan 08, 2009 at 09:03:35PM +0100, Sam Ravnborg wrote:
> On Thu, Jan 08, 2009 at 11:29:58PM +1100, Julian Calaby wrote:
> > Hi all,
> > 
> > This patch set eliminates most of the definitions within 
> > arch/sparc/kernel/sparc_ksyms_*.c by moving them to their rightful places.
> > 
> > This is done within patches 1-3.
> > 
> > Note that this work was originally performed by Sam Ravnborg and these 
> > patches have been rebased and added to by myself.
> > 
> > I've tried to reflect this in the commit messages but may have gotten it 
> > a little wrong.
> > 
> > Patches 4 and 5 are cleanups that I had in my tree for an eventual 
> > oplib_*.h unification - but as this screws up my original patches and 
> > they're so small, I figured this'd be as good a time as any to send them.
> > 
> > Changes in version 2:
> > 1. Patches 2 and 3 have a few more includes added to the modified files.
> > 2. It shouldn't be word wrapped this time!
> 
> Hi Julian.
> 
> I have tested your patches by applying them one-by-one
> and done both sparc and sparc64 builds.
> 
> Everything worked as expected - good work!

I forgot to mention that I also looked through all the patches
and everything looked good(*).

(*) It does not look "good" that we have all the local declarations
in ksyms.c but to eliminate them is another set of patches that
has lower priority.

	Sam

Re: [PATCH v2 0/5] Eliminate most of sparc_ksyms_*.c

[Julian Calaby]

On Fri, Jan 9, 2009 at 07:03, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Thu, Jan 08, 2009 at 11:29:58PM +1100, Julian Calaby wrote:
>> Hi all,
>>
>> This patch set eliminates most of the definitions within
>> arch/sparc/kernel/sparc_ksyms_*.c by moving them to their rightful places.
>>
>> This is done within patches 1-3.
>>
>> Note that this work was originally performed by Sam Ravnborg and these
>> patches have been rebased and added to by myself.
>>
>> I've tried to reflect this in the commit messages but may have gotten it
>> a little wrong.
>>
>> Patches 4 and 5 are cleanups that I had in my tree for an eventual
>> oplib_*.h unification - but as this screws up my original patches and
>> they're so small, I figured this'd be as good a time as any to send them.
>>
>> Changes in version 2:
>> 1. Patches 2 and 3 have a few more includes added to the modified files.
>> 2. It shouldn't be word wrapped this time!
>
> Hi Julian.
>
> I have tested your patches by applying them one-by-one
> and done both sparc and sparc64 builds.
>
> Everything worked as expected - good work!

Thanks for testing and reviewing them.

Hopefully we can fix the declarations at some point.

My stance on this is: as this functionality that is defined in
assembler, having nasty C code is acceptable - providing that it's
documented. (which we could improve somewhat)

I plan to merge sparc_ksyms_*.c into (possibly) another ksyms.c,
however I have a compile error in a module to fix first.

Thanks for all your help on this and for looking over my patches.

-- 
Julian Calaby

Email: julian.calaby@gmail.com

Re: [PATCH v2 0/5] Eliminate most of sparc_ksyms_*.c

[David Miller]

From: "Julian Calaby" <julian.calaby@gmail.com>
Date: Fri, 9 Jan 2009 08:23:41 +1100

> My stance on this is: as this functionality that is defined in
> assembler, having nasty C code is acceptable - providing that it's
> documented. (which we could improve somewhat)

Note, we can probably do this automatically without having
to define a symbol exporting macro for assembler code.

Just add some annotation to the assembler files, then
some script or similar processes the *.S files looking
for the symbol export annotations and uses that to
generate the ksyms.c file.

Nice project for someone who is bored :)

Re: [PATCH v2 0/5] Eliminate most of sparc_ksyms_*.c

[Sam Ravnborg]

On Thu, Jan 08, 2009 at 01:33:39PM -0800, David Miller wrote:
> From: "Julian Calaby" <julian.calaby@gmail.com>
> Date: Fri, 9 Jan 2009 08:23:41 +1100
> 
> > My stance on this is: as this functionality that is defined in
> > assembler, having nasty C code is acceptable - providing that it's
> > documented. (which we could improve somewhat)
> 
> Note, we can probably do this automatically without having
> to define a symbol exporting macro for assembler code.
> 
> Just add some annotation to the assembler files, then
> some script or similar processes the *.S files looking
> for the symbol export annotations and uses that to
> generate the ksyms.c file.

Arnd Bergman once posted a patchset that allow us to do the export in .S files.

Google for "add support for exporting symbols from .S files"

Could we resurface this patchset?

Arnd?

	Sam

Re: [PATCH v2 0/5] Eliminate most of sparc_ksyms_*.c

[Arnd Bergmann]

On Thursday 08 January 2009, Sam Ravnborg wrote:
> Arnd Bergman once posted a patchset that allow us to do the export in .S files.
> 
> Google for "add support for exporting symbols from .S files"
> 
> Could we resurface this patchset?

The patch should still work. The only concern with this was that it
still isn't sufficient to kill ksyms.c on architectures that export
symbols from libgcc.

	Arnd <><

Re: [PATCH v2 0/5] Eliminate most of sparc_ksyms_*.c

[Sam Ravnborg]

On Thu, Jan 08, 2009 at 11:20:46PM +0100, Arnd Bergmann wrote:
> On Thursday 08 January 2009, Sam Ravnborg wrote:
> > Arnd Bergman once posted a patchset that allow us to do the export in .S files.
> > 
> > Google for "add support for exporting symbols from .S files"
> > 
> > Could we resurface this patchset?
> 
> The patch should still work. The only concern with this was that it
> still isn't sufficient to kill ksyms.c on architectures that export
> symbols from libgcc.

We have the opportunity to move all EXPORT_SYMBOLS() to
the place where the functions are defined.
The documentation effect that tell the reader:

   "Hey, I may be used by a module so take extra care"

That is enough to warrant the inclusion of this patch.
The aim here is IMO not to kill all the *ksyms.c files but
rather to document which functions are exported at their
definition.

I could see there were some comments about different .align
and the like.

Can I ask you to repolish these bits and submit it to linux-arch.

Thanks,
	Sam