Todd Vierling 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. I'm not too happy about (*p->p_emul->e_trapsignal)()
and such, but those seem as necessary evil.

With current path translation scheme, only emulations pay the price,
there is no bloat within native interface. The current interface
is fairly unified already - struct emul contains a pointer to
pathname prefix, and this is used when generic path massaging
routines are called.  The emulation code only needs to add hooks
to the path translation routines, that's all. Those wrappers are
not too painful to add and honestly, how often you add new emulations?

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.

Jaromir 
-- 
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.NetBSD.org/Ports/i386/ps2.html
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-