mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Dike <jdike@karaya.com>
To: ebiederm@xmission.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux 2.5.60
Date: Wed, 12 Feb 2003 23:12:38 -0500	[thread overview]
Message-ID: <200302130412.XAA05507@ccure.karaya.com> (raw)

ebiederm@xmission.com said:
> Or it can use the linker to play games with symbol names to move the
> kernel off into it's own separate name space.
>
> This sounds like a good opportunity to figure out which makes most
> sense  and future proof UML. 

OK, I thought I had a cunning plan to deal with this problem, but it falls
apart when you actually think about it some.

The problem is this -
	2.5.60 introduces sigprocmask as a kernel function
	UML calls sigprocmask from its userspace code (the stuff that interacts
with libc rather than the kernel) and it expects to get the libc sigprocmask
which makes a system call into the host kernel
	Instead, it gets the new kernel sigprocmask, and things go downhill
rapidly from there

My cunning plan was this -
	link UML's userspace code into a single .o (call it userspace.o), 
similarly link its kernel code into a single .o (kernel.o)
	do an incremental link of userspace.o against libc, thereby resolving
sigprocmask to the libc version
	link all of UML together, kernel code and userspace code.  Any remaining
references to sigprocmask will be in kernel code, and will resolve to the new
kernel sigprocmask.

This falls apart for a couple of reasons -
	I get a duplicate definition of sscanf which I can't get rid of (libc
vs. lib/vsprintf.c)
	More seriously, this assumes a static link and breaks the dynamic build
of UML

In order for this to work, references from userspace.o which can be resolved
in libc must somehow survive the link against the kernel code unresolved.
That is, references to things not in libc must be resolved from kernel code
and references to things in libc must be resolved from libc even if there is
a symbol with the same name in the kernel.  I don't see any way of doing this.

The only other solution I see is to rename the kernel sigprocmask.  Oleg Drokin
has done with this with a 
	-Dsigprocmask=__sigprocmask
on kernel code compiles, and I've done it at link time with objcopy.  This 
sucks, but it does have the great advantage that it actually works.

Anyway, if there's something better, I really want to know about it.

				Jeff


             reply	other threads:[~2003-02-13  4:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-13  4:12 Jeff Dike [this message]
2003-02-13  8:19 ` Oleg Drokin
  -- strict thread matches above, loose matches on Subject: below --
2003-02-10 19:08 Linus Torvalds
2003-02-10 20:41 ` Maciej Soltysiak
2003-02-10 21:11   ` Stephen Hemminger
2003-02-10 21:25     ` James Lamanna
2003-02-10 22:54       ` Linus Torvalds
2003-02-10 22:21 ` John Cherry
2003-02-11  7:08 ` Oleg Drokin
2003-02-11  7:38   ` Linus Torvalds
2003-02-12  8:11     ` Eric W. Biederman
2003-02-12 11:49       ` Jeff Dike
2003-02-13 23:25         ` Werner Almesberger
2003-02-11 15:16 ` Zephaniah E. Hull
2003-02-11 22:47   ` Andrew Morton
2003-02-11 22:54     ` Andrew Morton
2003-02-14 16:56       ` Zephaniah E. Hull
2003-02-11 16:23 ` Russell King
2003-02-11 17:06   ` Linus Torvalds
2003-02-12  2:47     ` David S. Miller
2003-02-11 22:00 ` Rudmer van Dijk
2003-02-12 10:05 ` Ingo Oeser

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=200302130412.XAA05507@ccure.karaya.com \
    --to=jdike@karaya.com \
    --cc=ebiederm@xmission.com \
    --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

Powered by JetHome