in ksh93 non-special builtin binding is done via PATH search by maniplating the PATH a non-privileged user can insert dirs ahead of the builtin binding dir -- so it just becomes a problem of setting up the PATH dir order to suit individual needs, even to the point of bypassing all non-special builtins
a kernel-based solution for solaris might scream but it won't eliminate ksh builtins/plugins via shared libs because other systems won't have that feature also, "compile time caching" for ksh only applies to the ksh non-special that are bound to dirs -- other builtins/plugins are bound at runtime via builtin(1) on user and/or system supplied plugin shared libs On Sat, 27 Mar 2010 17:02:45 +0000 Jeremy Harris wrote: > On 03/27/2010 03:39 PM, Chris Pickett wrote: > > On Thu, Mar 18, 2010 at 4:41 PM, Darren J Moffat > > <[email protected]> wrote: > >> What benefit does this case bring ? > > > > First at all you do not go through fork() and be a lot faster. > The intent appears to be better performance; generally a good thing. > I'm concerned about the implementation and its implications. > It seems to me that this is an example of all problems in programming > being an exercise in caching. The item being cached is a utility > executable, and the cache load time is during compilation of the > proposed new ksh93 implementation. > Unfortunately, the cache invalidation and/or reload is also the latter > time. I think this is a mistake. If I, with suitable permissions, cannot > replace the binary of a utility in the filesystem of my system and > get the expected changed behaviour, it is no longer Unix. This > is an architectural issue. > Gnu-ness or otherwise is not relevant to this argument. > As a possible alternate architecture, I suggest > 1) kernel support for pre-linking arbitrary executables with > a running process, such that a call into such an executable image > does not require a system-call > 2) kernel support for de-linking the above, from the running > process > 3) means for a running process to be notified of changes to > the filesystem object backing an executable, without the > use of a system-call when no such change has been made > We've been into this area before. Let's not make such a mistake as vfork was > again. > -- > Jeremy Harris > _______________________________________________ > opensolaris-arc mailing list > [email protected] _______________________________________________ opensolaris-arc mailing list [email protected]
