On 2006.08.22 17:29:02 +1000, Benjamin Herrenschmidt wrote:

On Mon, 2006-08-21 at 17:12 +0200, Arnd Bergmann wrote:

quoted

On Monday 21 August 2006 02:36, Paul Mackerras wrote:

quoted

quoted

Iit turned out most of the architectures that already implement
their own execve() call instead of using the _syscall3 function
for it end up passing the return value of sys_execve down, 
instead of setting errno.

I really don't like having an "errno" variable in the kernel.  What if
two processes are doing an execve concurrently?

The point is that we have two different schemes in the kernel that
conflict:

alpha, arm{,26}, ia64, parisc, powerpc and x86_64 pass the error
code from execve, all others pass -1 and set the global errno.

All other need to be fixed then... having an errno is just plain wrong.

I'm working on a patch loosely based on Arnd's that changes the
in-kernel syscall macros to directly return the error codes. Once
kernel_execve is implemented for each arch, only um should remain as a
user and I found only two calls there that care about the exact
non-zero return value, both are simple to adapt.
That should allow to get rid of errno completely. If someone knows a
reason why this is destined to fail (maybe syscalls returning char?!),
please let me know before I waste too much time on it ;)

Björn