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).
Thanks,
Chase
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