From: Arnd Bergmann <arnd@arndb.de>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: "Andrew Morton" <akpm@osdl.org>,
"Björn Steinbrink" <B.Steinbrink@gmx.de>,
rusty@rustcorp.com.au, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Return real errno from execve in ____call_usermodehelper
Date: Sun, 20 Aug 2006 15:01:28 +0200 [thread overview]
Message-ID: <200608201501.29296.arnd@arndb.de> (raw)
In-Reply-To: <20060819084233.GA25767@flint.arm.linux.org.uk>
On Saturday 19 August 2006 10:42, Russell King wrote:
> Maybe what we should be thinking of doing is changing execve() calls
> to kernel_execve() which returns the error code.
>
> This way, architectures are free to implement execve() whatever way
> they wish - and if they're concerned about using errno, that's their
> own implementation specific detail.
Sounds good, it means we could finally kill __KERNEL_SYSCALLS__ along
with lib/errno.c.
I guess a fallback for those that haven't yet done kernel_execve could be
#ifdef CONFIG_ARCH_KERNEL_EXECVE
extern int kernel_execve(const char *filename,
char *const argv[], char *const envp[]);
#else
static inline int kernel_execve(const char *filename,
char *const argv[], char *const envp[]);
{
int errno;
mm_segment_t old_fs = get_fs();
set_fs(KERNEL_DS);
/* the kernel syscall macro modifies errno */
execve(filename, argv, envp);
set_fs(old_fs);
return errno;
}
#endif
With that in place, we can remove the global errno right away, and the
kernel syscalls for any architecture that implements its own kernel_execve.
Arnd <><
next prev parent reply other threads:[~2006-08-20 13:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-19 7:30 [PATCH] Return real errno from execve in ____call_usermodehelper Björn Steinbrink
2006-08-19 8:14 ` Andrew Morton
2006-08-19 8:42 ` Russell King
2006-08-20 13:01 ` Arnd Bergmann [this message]
2006-08-20 13:47 ` Björn Steinbrink
2006-08-20 17:13 ` [PATCH] introduce kernel_execve function to replace __KERNEL_SYSCALLS__ Arnd Bergmann
2006-08-20 17:36 ` Chase Venters
2006-08-20 18:25 ` Andrew Morton
2006-08-20 18:32 ` Chase Venters
2006-08-20 19:45 ` Björn Steinbrink
2006-08-20 19:50 ` Arjan van de Ven
2006-08-20 20:11 ` Björn Steinbrink
2006-08-20 20:20 ` Arjan van de Ven
2006-08-20 20:36 ` Björn Steinbrink
2006-08-20 20:40 ` Arjan van de Ven
2006-08-21 1:55 ` Jeff Dike
2006-08-20 20:33 ` Arnd Bergmann
2006-08-20 19:31 ` Arnd Bergmann
2006-08-21 0:36 ` Paul Mackerras
2006-08-21 15:12 ` Arnd Bergmann
2006-08-21 15:17 ` Russell King
2006-08-22 7:29 ` Benjamin Herrenschmidt
2006-08-22 8:00 ` Björn Steinbrink
2006-08-22 10:06 ` Arnd Bergmann
2006-08-22 13:39 ` Jeff Dike
2006-08-22 15:13 ` Arnd Bergmann
2006-08-22 15:37 ` Jeff Dike
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=200608201501.29296.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=B.Steinbrink@gmx.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=rusty@rustcorp.com.au \
/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.