public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Module loader preparation
Date: Fri, 18 Oct 2002 12:55:36 +1000	[thread overview]
Message-ID: <20021018025632.009BE2C0BB@lists.samba.org> (raw)
In-Reply-To: Your message of "Thu, 17 Oct 2002 11:02:14 EST." <Pine.LNX.4.44.0210171057210.6301-100000@chaos.physics.uiowa.edu>

In message <Pine.LNX.4.44.0210171057210.6301-100000@chaos.physics.uiowa.edu> yo
u write:
> Converting things to module_init() is certainly a good thing, but having 
> to provide fake init functions for modules which don't need them doesn't 
> look so nice.

Since there are only a couple, I didn't get exotic.

> Did you consider just generating the info you need unconditionally in 
> include/linux/module.h and then removing duplicates for multi-part modules 
> using ld's link-once (I didn't try that yet, but it seems doable and would 
> also remove duplicated .modinfo.kernel_version strings and the like)

Didn't think of it, to be honest, and I can't find any reference to
link-once glancing through the ld info page.

You'll still have problems with objects linked into two modules
(ip_conntrack_core being the typical one), but we could ban these and
just #include the .c file rather than linking.

Really, the number of modules which do this is so small, the code to
add init function to them is less than the change in the build system
to get tricky.

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

  reply	other threads:[~2002-10-18  2:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-17  3:31 [PATCH] Module loader preparation Rusty Russell
2002-10-17 13:33 ` Christoph Hellwig
2002-10-18  1:39   ` Rusty Russell
2002-10-17 16:02 ` Kai Germaschewski
2002-10-18  2:55   ` Rusty Russell [this message]
2002-10-18 21:52     ` Kai Germaschewski

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=20021018025632.009BE2C0BB@lists.samba.org \
    --to=rusty@rustcorp.com.au \
    --cc=kai@tp1.ruhr-uni-bochum.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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