Subject: Re: Removing compat/aout
To: Jaromir Dolecek <jdolecek@netbsd.org>
From: Todd Vierling <tv@wasabisystems.com>
List: tech-kern
Date: 03/08/2002 14:36:58
On Fri, 8 Mar 2002, Jaromir Dolecek wrote:

: > Right, but you still need to inject those macros all over the place.  I'd be
: > curious as to how much a system would be slowed down on native file
: > accesses if the path translation took place within namei() itself for native
: > or emul.  (This would allow many of the emul functions simply to collapse to
: > their sys_*() counterparts.)
:
: I'd be highly reluctant to add _any_ emulation code to native code path.
: I'm glad that tree is fairly clean on this regard nowadays and all
: those silly #ifdef COMPAT_FOO hooks moved to compat-specific code
: where they belong.

Well, path translation is needed for pretty much all emuls except native, so
what's the overhead of finding a NULL pointer in that spot when doing a
namei lookup for a native binary?  This is what we'd need to benchmark.

Plus, you could always skip the check entirely if *no* COMPAT_<os> options
are given.

: It's necessary to do structure translation anyway quite often, so you
: don't really earn much (if anything) moving the path translation
: hooks into generic code.

Struct translation is one thing, but have you actually looked to see how
many *completely identical* (except for pathname lookups) codepaths exist in
src/sys/compat/* vs. src/sys/kern?  There's quite a few.

Ideally, a lot of the compat code could be collapsed to a struct translation
bit, calling a common factored-out function from sys/kern, and letting
namei() determine (if the path prefix is non-NULL) whether to do an extra
translation lookup.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/