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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox