Subject: Killing stackgap
To: None <tech-kern@netbsd.org>
From: David Laight <david@l8s.co.uk>
List: tech-kern
Date: 03/10/2007 22:11:29
I've made a start on killing the 'stackgap' which is a rather nasty
hack used to do compat system calls.

I guess the idea seemed neat at the time, but it is a really horrid hack.
But the real problem is that it just doesn't work properly for threaded
programs - whether they use LWPs, SA or any other form of the clone()
system call.
If two threads make system calls that both need the stackgap, they are
likely to end up with parts of each others data!
With the SMP threads this is even more likely, since the 'biglock' need
not be held across copyin/out...

However a lot of the stackgap use is in the CHECK_ALT_EXIST/SYMLINK/CREATE
define used on every file lookup (under compat) to call emul_find() to
check for files under p->p_emul->e_path before the normal lookup.

As well as being horribly inefficient (it must be calling namei() and
then throwing away the answer - only to have namei() process the path
again later), I suspect there might be some scope for utilising the
timing window for something.

I presume that p->p_emul->e_path (which ought to be a vnode) is used
for absolute pathnames, and acts a little like the chroot base - except
that if the file isn't found the nornal lookup is done.

This makes be think that this ought to be a feature of namei() itself.
Such a change would also mean that rafts of compat code could be killed
outright.

	David

-- 
David Laight: david@l8s.co.uk