public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jonas Bonn <jonas@southpole.se>
Cc: Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH 14/19] OpenRISC: Module support
Date: Fri, 24 Jun 2011 12:05:31 +0200	[thread overview]
Message-ID: <201106241205.32037.arnd@arndb.de> (raw)
In-Reply-To: <1308905525.6699.23.camel@localhost>

On Friday 24 June 2011, Jonas Bonn wrote:
> On Wed, 2011-06-22 at 16:26 +0200, Arnd Bergmann wrote:
> > I think that an easy way to do that would be to add to kernel/module.c
> > code like:
> > 
> > #ifndef module_alloc
> > void *module_alloc(unsigned long size)
> > {
> >       return vmalloc(size);
> > }
> > #endif
> > 
> 
> I noticed that kernel/module.c already has this:
> 
> unsigned int __weak arch_mod_section_prepend(struct module *mod,
>                                              unsigned int section)
> 
>
> Is using a __weak attribute on the default (generic) implementations a
> better approach?

I normally don't like using __weak, because it more easily confuses
readers about which version is actually used.

> > Then each architecture that needs a special version can do
> > #define module_alloc(size) module_alloc(size)
> > in their respective asm/module.h
> 
> With the __weak variant this wouldn't be necessary...

Correct. I certainly wouldn't want to see both methods mixed in the
same file. Rusty is maintaining the module loader, maybe he has
a preference.

Rusty, we were discussing the fact that most module loader files
are providing very similar (mostly empty) functions, and that it would
be nice if the new openrisc architecture would only have to provide
apply_relocate_add(), which is actually arch specific, while it could
be changed to use the defaults for everything else.

	Arnd

  parent reply	other threads:[~2011-06-24 10:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1308483825-6023-1-git-send-email-jonas@southpole.se>
     [not found] ` <1308483825-6023-15-git-send-email-jonas@southpole.se>
     [not found]   ` <31626.1308686616@turing-police.cc.vt.edu>
2011-06-22 14:26     ` [PATCH 14/19] OpenRISC: Module support Arnd Bergmann
2011-06-22 14:26       ` Arnd Bergmann
2011-06-22 19:08       ` [PATCH 1/1] Add default implementations for moduleloader hooks Jonas Bonn
2011-06-22 19:08         ` Jonas Bonn
2011-06-22 19:14       ` [PATCH 14/19] OpenRISC: Module support Jonas Bonn
2011-06-22 19:58         ` Arnd Bergmann
2011-06-22 20:05           ` Jonas Bonn
2011-06-22 20:46             ` Arnd Bergmann
2011-06-24  8:52       ` Jonas Bonn
2011-06-24  8:52         ` Jonas Bonn
2011-06-24 10:05         ` Arnd Bergmann [this message]
2011-06-24 11:06           ` Rusty Russell
2011-06-24 11:06             ` 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=201106241205.32037.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=jonas@southpole.se \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox