From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Ryan C. Gordon" <icculus@icculus.org>, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 2/2] binfmt_elf: FatELF support for kernel modules.
Date: Mon, 26 Oct 2009 12:14:03 -0700 [thread overview]
Message-ID: <4AE5F4FB.3000506@goop.org> (raw)
In-Reply-To: <20091024121421.2e530635@lxorguk.ukuu.org.uk>
On 10/24/09 04:14, Alan Cox wrote:
>> Well, ideally a fat module would allow modules for multiple kernels to
>> be bundled together (same and/or different architectures), which is
>> primarily useful for 3rd-party binary distributions.
>>
> You would need thousands and thousands of binaries to do that. I'm not
> sure the gigabyte sized module file would be too popular. It would be
> easier to recompile it even automatically (take a look at the Dell stuff
> for this)
>
Yeah, I should have been a bit clearer here. My point was that if this
facility were to exist, it would seem logical to support that kind of
mode of operation (since at least at one point vendors shipping binary
modules would seem to include a few enterprise distro builds and hope
that would cover it). But that doesn't seem like a very good idea.
Auto-building schemes are better, but they still always seem to break.
J
next prev parent reply other threads:[~2009-10-26 19:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-19 14:41 [RFC][PATCH 2/2] binfmt_elf: FatELF support for kernel modules Ryan C. Gordon
2009-10-20 0:12 ` Jeremy Fitzhardinge
2009-10-20 4:54 ` Ryan C. Gordon
2009-10-23 22:24 ` Jeremy Fitzhardinge
2009-10-24 0:31 ` Ryan C. Gordon
2009-10-24 11:14 ` Alan Cox
2009-10-26 19:14 ` Jeremy Fitzhardinge [this message]
2009-10-26 19:59 ` Alan Cox
2009-10-30 2:25 ` Ryan C. Gordon
2009-10-30 10:32 ` Alan Cox
2009-10-30 14:19 ` Ryan C. Gordon
2009-10-20 8:33 ` Américo Wang
2009-10-21 8:06 ` Ryan C. Gordon
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=4AE5F4FB.3000506@goop.org \
--to=jeremy@goop.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=icculus@icculus.org \
--cc=linux-kernel@vger.kernel.org \
/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