David Korn wrote: > > Subject: Re: [ksh93-integration-discuss] Solaris packaging of ksh93 > components (libast, libcmd, libdll, libshell) > -------- > > There are pros and cons to having libast, libcmd, and libshell as separate > shared libraries rather than statically linking libshell to libast and libcmd. > > The primary benefit of keeping each as shared libraries is > that applications would be able to use the services provide > by libast and libcmd. One of the components of libast is sfio, which > is an I/O library similar to stdio, but more consistent, > more extensible, and typically faster than stdio. Programs > like perl have been configured to be able to use sfio for > better performance. sfio provides a <stdio.h> header file that > allows it to be used with the stdio interface. > sfio uses memory mapping for input by default and dynamic buffer sizing > for random access. It supports strings and files symetrically.
Ok... if perl can make use of sfio in libast (with performance improvements) then this is IMO a very good justification to handle it as a seperate library. April - do you know who at Sun maintains the perl version shipped with Solaris (I've added alan.burlison at sun.com per suggestions from irc://irc.freenode.org/#opensolaris) ? > libshell, which provides the shell functionality > relies heavily on each of these components. Because > it uses sfio, and sfio provides a stdio interface as well, > extensions written for libshell can use either sfio or stdio. > > ksh93 has the ability to load shared libraries at run time > to extend the functionality of the shell by adding built-ins > and/or other extensions like tksh (tk+ksh), and dtksh (Xlib+ksh). > In addition libshell can be embedded into other applications > to provide shell functionality. > > If libast is statically linked, then extensions to ksh can > only use functions from libast that the libshell has statically > linked in unless the extension also statically links with libast. Given the fast that there is already a (possible) consumer (perl!) of libast (excluding ksh93 itself) it may be likely that we want libast to be a seperate library... :-) > Libcmd provides POSIX conforming implemenations of many > common commands including all of the following: > basename.c [snip] > One other side benefit of having these as built-ins is that > there is not ARG_MAX limit since exec*() is not used. > > With our i-paq implementation, were replaced all of these commands > with a single command (hard linked by name) that just invoked > the corresponding builtin. The result was the the size for ksh, > and these commands + libcmd + libshell + libast took less space > then these commands did. Casper Dik already suggested something similar for Solaris, however I am not sure whether all builtins behave like the original Sun commands so replacing them may not be that easy... ;-/ In theory we could replace the binaries in /usr/xpg4/bin/ with those from libcmd - but then there are also binaries in /usr/xpg6/bin/ which behave sightly differently. Also testing the changes would be not easy. IMO at first we should focus on ksh93, libast and libshell... > If libshell, libcmd, and libast are separate, they will > all need to be on the boot disk assuming that ksh > will need to run at boot time. It would work when we have libast a seperate dynamic library and integrate libcmd+libdll into libshell.so, right ? > Note that if you want to use create shell extensions, you will > need <shell.h> and <shell.h> uses many of the other ast headers. > It would be best if you put all the ast headers in /usr/include/ast. > This way none will conflict with headers in /usr/include. > Programs that want to use the libast stdio, would need to specify > -I/usr/include/ast > and link with -last. Uhm... uhm... is there no standard location for <shell.h> ? I am not 100% happy with having it in something like /usr/include/ast/ ... something like /usr/include/shell/ sounds better for me (since I am planning some new stuff here (like a threadsafe version of libshell)) ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
