public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	don.mullis@gmail.com, david@fromorbit.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: modules, "modules" and CONFIG_LIST_SORT
Date: Sun, 7 Mar 2010 10:12:48 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1003070959490.4033@localhost.localdomain> (raw)
In-Reply-To: <4B93D63B.1040403@oracle.com>



On Sun, 7 Mar 2010, Randy Dunlap wrote:
> On 03/07/10 03:23, Linus Torvalds wrote:
> > 
> > Honestly, personally I'd rather have a real library that modules can link 
> > to _before_ even loading into kernel space, but that's not how we've 
> > traditionally done things. So I guess we should just revert that commit.
> 
> xfs also needs "select LIST_SORT".  I posted a patch for that a few days
> ago and now Christoph Hellwig has asked me to send the patch directly to Linus,
> but if Linus is going to revert the 'config LIST_SORT' patch, I'll skip it.

Ok, it's reverted in my tree now, I'll push out soon.

That said, I was serious about the "real library" thing. I do wonder if we 
should add a "link with standard kernel libraries" phase to the final 
module link, so that we can stop exporting silly things, and handle cases 
like this sanely without forcing it on everybody just because some module 
_might_ need it.

For example, I've always hated how we export the 'libgcc' kind of symbols 
too. I think we'd generally be _much_ better off just linking them into 
the module directly, even if that means that we'll have multiple copies. I 
hate the things like

	EXPORT_SYMBOL(__ashldi3);

that various architectures use. They have _nothing_ to do with real kernel 
interfaces, and are usually really small. And on several architectures a 
direct-linked call can be optimized by the linker in ways that external 
linkage cannot, so it might even improve code in some cases.

				Linus

      reply	other threads:[~2010-03-07 18:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-07  9:12 modules, "modules" and CONFIG_LIST_SORT Alexey Dobriyan
2010-03-07 11:23 ` Linus Torvalds
2010-03-07 16:37   ` Randy Dunlap
2010-03-07 18:12     ` Linus Torvalds [this message]

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=alpine.LFD.2.00.1003070959490.4033@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=don.mullis@gmail.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    /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