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(). > I'm not adverse to designing something better (I like the idea), but my > first gut instinct is "not this case". Right. Well, maybe, now that it's a full case I think isaexec optimization could certainly be on the table. > Modifying $PATH is a crummy solution, I agree, but as an interim hack to Not only crummy. We won't do it. That ship has sailed. > enable delivery for the few users that need the 64-bit semantics (and I > think the number that actually do need them for these apps is almost > vanishingly small) they have a workaround until we can come up with > something better. I'd rather we come up with something better. PATH monkeying should be seen as completely unacceptable here. > (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. > (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. 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). Nico --
