April Chin wrote: > Thank you for this information! > Some questions & comments below...
Ok... [snip] > > - usr/src/cmd/ksh/ is just the ksh93 frontend binary which directly > > calls into libshell.so (which is ksh93 in a shared library). Since the > > AST sources keep the frontend source file (sh/pmain.c) which contains > > the |main()| function together with the other libshell sources we're > > doing simply the same (e.g. usr/src/cmd/ksh/ fetches the source file > > from usr/src/lib/libshell/common/) > > > > - "src/cmd/ksh/Makefile.ksh93switch" is a small hack for > > OpenSolaris-based distributions and testing. It contains a small switch > > which can be set to install ksh93 as /usr/bin/ksh and enable a version > > of |libc::wordexp()| which uses ksh93. The switch is OFF by default but > > can be enabled on demand, e.g. for testing the migration of /usr/bin/ksh > > to ksh93 status and for OpenSolaris-based distributions who wish to > > avoid shipping the propiretary Solaris ksh monstrosity. > > AFAIK it doesn't really fit into OS/Net but it would still be nice to > > take it as it is highly usefull for the ksh93-migration and > > OpenSolaris-based distributions. > > I think this is very useful as well. Since this makes no change for > Solaris builds I'd like to include this and the switch-dependent > wordexp.c change in the putback. Ok... commited as http://polaris.blastwave.org/changeset/291 Note that if |WRDE_NOCMD| is requested this version requires ksh93r+ since it uses "set -o restricted" to switch to "restricted" shell mode (rksh) once all setup is done (e.g. my |libc::wordexp()| version generates a mini-script which takes care of all the stuff instead of the open()/close()/dup()-massacre in the original Sun version. Since stream redirection cannot be done in "restricted" mode we start ksh93 normally, setup all neccesary stuff and then switch to restricted mode). BTW: IMO it should be easy to adopt the current version of Sun ksh - we only have to implement a similar way to switch it to "restricted" mode on demand via "set -o restricted" - then we would only need one version of |libc::wordexp()| ... > > - libcmd is a merge of Solaris libcmd (which only contains the API to > > read files in /etc/default/, e.g. |defopen()|, |defread()|, |defcntl()|) > > and ksh93's libcmd. The API added from the ksh93 version only contains > > function names starting with "b_" (for "b_" for (shell) builtin), e.g. > > |b_basename()|. A quick scan through an installed Solaris 10U1 machine > > (full install+OEM support) shows no other applications+libraries > > employing a similar naming scheme except one binary: dtksh (because it > > is ksh93-base, too :-) ). Since dtksh does not use or reference > > libcmd.so there should be no problem (the Solaris libcmd API is marked > > as SUNWprivate, e.g Sun owns this API, it's private and all sources > > which use it are under control by Sun). > > I'm wondering what method you used here...I'm assuming something > like elfdump of binaries on the installed system? Basically you can reproduce it using % (find /usr -type f | egrep -v "\.so|\.a" | while read i ; do [ ! -x "$i" ] && continue ; x="$(elfdump "$i" 2>/dev/null | egrep "FUNC GLOB.* b_")" ; [ "$x" != "" ] && printf "## %s:\n%s\n" "$i" "$x" ; done ) # however this doesn't seperate between "provided" and "consumed" symbols and whether they are accessible externally... [snip] > > * The following OS/Net source files are added or modified by the > > ksh93-integration project (based on the output of % svn diff > > svn://svn.genunix.org/on/tags/b37/usr > > > svn://svn.genunix.org/on/branches/ksh93/gisburn/prototype002/m1_ast_ast_imported > /usr > > # ): > > -- snip -- > > -- snip -- > > > > > > I'll send you separate e-mail > to see if I have the correct list of the new library interfaces. Ok... > > * Interfaces: [snip] > > The components in /usr/bin/ have the stabilty status "Commited" (I hope > > this is the right term... :-) ), the library interfaces are "Private" > > for now (actually "semi-private" as ksh93-based shells shipped with > > Solaris such as dtksh, tksh etc. should be able to use it, however Sun > > does not seem to have a concept of "Semi-private" for such a case) > > For the private library interfaces we can make them: > Project Private, which is for use only by the ksh93 project; > Consolidation Private, for use only by our OS-Net consolidation > (the source we have access to); or > Sun Private, for use also by other consolidations in Sun with > separate source gates, such as those for dbx or dtksh. > > Since we want to allow other Sun applications to use libshell, we'd want to > make it Sun Private. > > The existing libcmd interfaces (defread, defopen, defcntl) > are Sun Private, but I assume this does not require the > new interfaces in libcmd to have this same scope...someone can correct me > if this is wrong. They need to have the same scope as the API in libshell as libshell will load them - and other commands/shells based on libshell.so may want to preload, override or superset these builtins which may require access to these symbols, too. > So my question is, what is the proper scope for the > new libcmd interfaces, as well as those for libast and libdll? > Sun Private, or one of the more limited categories? See above... all the APIs in libshell, libcmd, libdll and libast should have the same status here... > I know you mentioned libast's usefulness by external applications, > but I don't think we want to commit these interfaces for external use yet. > Would an internal application such as dbx, require any of the other > interfaces other than libshell's? Yes since libshell partially depends on APIs such as sfio (sort of the AST version of a greatly enhanched stdio). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
