Re: lib/errno.c

[Chase Venters <chase.venters@clientec.com>]

On Tue, 1 Aug 2006, Chase Venters wrote:

> I'm curious if there's a reason we're still carrying "lib/errno.c". The 
> string "errno" is used pretty heavily but from a grep glance it seems any 
> users define it locally (and indeed, the concurrency issues with a global 
> 'errno' symbol mean it would be worthless except during boot, or maybe under 
> BKL).

OK, I think I figured out why it's still there -- an old bit of legacy 
that is now a hack to deal with _syscall macros? I'm guessing here, so it 
would be nice if someone told me if I'm on the right track:

 1. linux/unistd.h defines the extern for errno (perhaps for old export to 
user-space?)
 2. lib/errno.c defines the variable itself
 3. __syscall_return sets errno, probably for the benefit of old 
user-space

I'm wondering if we should drop lib/errno.c, #ifndef __KERNEL__ around the 
extern in unistd.h, and then fix up __syscall_return in 
include/asm-*/unistd.h to have two versions -- one when in __KERNEL__ that 
doesn't muck with errno, and one when not that does?

Alternatively / additionally, investigate changing execve() callers to use 
sys_execve() or do_execve(), rather than pounding back in through an 
interrupt?

Having a global 'errno' in the kernel just seems wrong -- if someone were 
to include unistd.h and then decide to use an 'int errno' in some 
function, then proceeds to forget to declare it on the stack, the code 
would build and leave a nice race condition hiding out.

Would a patch along these lines be acceptable, or is there something I am 
missing?

Thanks,
Chase
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/