From: Christoph Hellwig <hch@infradead.org>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] Support ia32 exec domains without CONFIG_IA32_SUPPORT
Date: Sun, 10 Oct 2004 10:10:47 +0000 [thread overview]
Message-ID: <20041010101047.GA28456@infradead.org> (raw)
In-Reply-To: <41643EC0.1010505@intel.com>
On Fri, Oct 08, 2004 at 03:37:10PM -0700, Arun Sharma wrote:
> On 10/8/2004 1:08 AM, David Mosberger wrote:
>
> >Unfortunately, that thread ran out in a rather unhelpful manner, as
> >far as I can see. Rusty seemed to agree that the performance-hit of
> >doing it all in user-level was unacceptably high, but I didn't see any
> >actual numbers. There was a suggestion to decouple the altroot from
> >the personality which makes some sense, but nobody actually did
> >anything about it?
> >
>
> I'd really like this issue to be resolved one way or the other. I'm not
> sure I've heard a convincing argument on why my original patch(which adds a
> new exec domain unconditionally) should not be applied.
>
> I'm fine with the attached patch to set the altroot via a system call as
> well.
I'd still like to see some number on how much smaller a userland emulation
is. Best using qumu because that's opensource and we simply don't care
about intel's propritary stuff. Else your patch looks pretty okay - but
I'd need to go through linux-kernel and hooking up to all architectures.
> -void set_fs_altroot(void)
> +int set_fs_altroot(const char __user *altroot)
> {
> char *emul = __emul_prefix();
>
> struct nameidata nd;
> @@ -905,12 +905,20 @@
> struct dentry *dentry = NULL, *olddentry;
> int err;
>
> + if (altroot) {
> + emul = getname(altroot);
> + if (IS_ERR(emul))
> + return PTR_ERR(emul);
> + }
the interface here is pretty awkward. I'd say rename this function to
__set_fs_altroot and always pass altroot as a kernel string here, do the
getname in sys_altroot and the __emul_prefix() in set_fs_altroot which will
be a one-liner wrapper.
prev parent reply other threads:[~2004-10-10 10:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-06 18:51 [PATCH] Support ia32 exec domains without CONFIG_IA32_SUPPORT Arun Sharma
2004-10-07 13:27 ` Christoph Hellwig
2004-10-07 23:44 ` Arun Sharma
2004-10-08 8:08 ` David Mosberger
2004-10-08 22:37 ` Arun Sharma
[not found] ` <mailman.1097403036.11924@unix-os.sc.intel.com>
2004-10-11 21:05 ` Arun Sharma
2004-10-11 21:05 ` Arun Sharma
2004-10-12 21:50 ` David Woodhouse
2004-10-12 21:50 ` David Woodhouse
2004-10-12 22:46 ` Arun Sharma
2004-10-12 22:46 ` Arun Sharma
2004-10-13 22:27 ` Arun Sharma
2004-10-13 22:27 ` Arun Sharma
2004-10-14 7:32 ` David Mosberger
2004-10-14 7:32 ` David Mosberger
2004-10-14 8:25 ` David Woodhouse
2004-10-14 8:25 ` David Woodhouse
2004-10-14 8:50 ` Jakub Jelinek
2004-10-14 8:50 ` Jakub Jelinek
2004-10-14 17:53 ` Arun Sharma
2004-10-14 17:53 ` Arun Sharma
2004-10-09 4:24 ` Luck, Tony
2004-10-10 10:10 ` Christoph Hellwig [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=20041010101047.GA28456@infradead.org \
--to=hch@infradead.org \
--cc=linux-ia64@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.