Nicolas Williams wrote:
> On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote:
> > Yes, isaexec is needed for correctness, but its not used on any
> > performance critical paths, and remains, IMO, an ugly hack rather than
> > an elegant solution.
>
> isaexec handling could move into the kernel if it had to to avoid the
> additional exec().
|isaexec()| cannot be moved into the kernel unless you can implement
CR#6474270 ("isaexec and magical builds" -
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270) from
the kernel, too.
[snip]
> > (I'm also looking for a way to allow this case to proceed forward,
> > without requiring it to block on a larger set of architectural problems
> > that the project team is probably ill-equipped to solve.)
>
> It's a full case now.
And I disagree. The original idea was to get rid of some limits in some
tools, not boil the ocean or start becoming a politician (and half of
the emails I got via PM strongly indicate that the mutations on top of
the original idea are political issues which should be handled via
ogb-discuss at opensolaris.org and not PSARC).
> > (As far as "something better", I think I prefer something along the
> > lines of how AFS handles it, where $VARIABLE could be used within a
> > symbolic link -- the kernel expands the variable when following the
> > symlink. But we shouldn't try to design the solution here, I think.)
>
> The ELF exec handler in the kernel could find the conditional logic to
> evaluate and tokens to expand, and just do it. This would be much safer
> than modifying the semantics of symlinks. And isaexec would remain, but
> the extra exec() would be avoided.
As said it wouldn't work (see above). And the |exec()| overhead for
_shell_ interpreters like "ksh93" is usually canceled out by using
builtin commands and avoiding that subshells |fork()| which more or less
eliminates gdamore's complains about isaexec in this case (and "yes" -
we did benchmark that). For "bash" it may be slighty different since it
|fork()|+|exec()|s a lot more than ksh93 but I still think it won't harm
users a lot.
> But one step at a time. This smacks me as premature optimization (even
> though the extra exec() is wasteful -- the point it is that optimizing
> isaexec now is premature for this discussion).
Right. And please don't implement anything which prevents us from
implementing CR#6474270 ("isaexec and magical builds").
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
