Peter Tribble wrote:
> On Mon, Feb 2, 2009 at 1:28 AM, Alan Hargreaves
> <ah89892 at sac.sfbay.sun.com> wrote:
> > I'm sponsoring this fast-track request on behalf of the
> > ksh93-integration project.
> >
> > Please note that this is an *open* case.
> >
> > Template Version: @(#)sac_nextcase %I% %G% SMI
> > This information is Copyright 2009 Sun Microsystems
> > 1. Introduction
> > 1.1. Project/Component Working Name:
> > ksh93 update 2
> > 1.2. Name of Document Author/Supplier:
> > Author: Alan Hargreaves
> > 1.3 Date of This Document:
> > 01 February, 2009
> > 4. Technical Description
> >
> > The release binding is the same as with the previous ksh93 project: a
> > patch/micro release of Solaris delivering through OS/Net. Stability
> > levels are as described below.
> >
> > Additional materials (man pages and diffs) can be found in the
> > 'materials' subdirectory.
> >
> > This project is an amendment to the Korn Shell 93 Integration project
> > (PSARC/2006/550, PSARC/2006/587, PSARC/2007/035 and PSARC/2008/344)
> > specifying the following additional interfaces:
> >
> > 1) Update of ksh93 interfaces
> > 1.1) New "typeset" variable type qualifier ("-C") to declare compound
> > variables
> > 1.2) New "typeset" option "-m" to rename/move a variable
> > 1.3) New "read" option "-C" to read a variable as compound variable
> > 1.4) New "print" option "-C" to print compound variables as a
> > single line
> > 1.5) New ksh93 math functions "log10", "j0", "j1", "jn", "y0",
> > "y1", "yn"
> > 1.6) Interface stability change of the POSIX shell command language
> > parts of the ksh93 language
> >
> > 2) An enhanced version of the "cmp" utility and an identical ksh93
> > built-in command
> >
> > 3) An enhanced version of the "cut" utility and an identical ksh93
> > built-in command
> >
> > 4) An enhanced version of the "comm" utility and an identical ksh93
> > built-in command
> >
> > 5) An enhanced version of the "paste" utility and an identical ksh93
> > built-in command
> >
> > 6) The addition of /usr/bin/print
> >
> > 7) An enhanced version of the "uniq" utility and an identical ksh93
> > built-in command
> >
> > 8) An enhanced version of the "wc" utility and an identical ksh93
> > built-in command
>
> Replacement of important components of the userland seems rather too important
> for a fast-track.
>
> I know that I'm certainly not happy about ripping out Solaris commands and
> replacing them with external commands.
Erm... these commands aren't "external" nor are we going to "rip them
out". The new commands will still be part of OS/Net (actually they _are_
already within OS/Net as part of usr/src/lib/libcmd/common/) and shipped
like the old commands (most of them remain in the same package but some
move from "SUNWesu" to "SUNWcsu" (which isn't a problem since "SUNWesu"
depends on "SUNWcsu")). The change is that:
- we get a living and cooperative upstream with which we do active
development and enhancements instead of just maintaining the "status
quo" (which was more or less the case for the commands we change in this
case)
- we get a 64bit clean codebase (which is _urgendly_ needed for Solaris
ports like SystemZ)
- we get a significant performance[1] boost on OpenSolaris/Indiana since
all these commands then run "inline"
- we reduce the system's resource usage (both disk space footprint and
memory usage (you'll find a similar appriach on embedded Linux versions
which use the "busybox" toolkit))
[1]=Short explanation: Using builtin commands saves at least one
|fork()|+|exec()| sequence and the whole work behind |setlocale()|. The
|fork()| itself is obviously a heavywheight operation but the |exec()|
can affect the performance of the _whole_ machine since the kernel must
make crosscalls to all CPUs to tear down the matching address space. Now
imagine a T5440 with 256 threads and lots of scripts running in
parallel... in that case each saved |exec()| is a significant
performance win.
> What happens when we need or want
> to diverge from upstream behaviour?
1. Nicolas already answered that question in
http://mail.opensolaris.org/pipermail/opensolaris-arc/2009-February/013756.html
... we can diverge from the upstream codebase but AFAIK there should've
be a need to do this because we _cooperate_ with upstream.
2. The tools we change in this ARC case are all defined by POSIX+SUS and
both the old and new commands conform to these standards. There is no
practical way to diverge from the POSIX+SUS behaviour since otherwise
we'll break lots of stuff. For the extensions beyond POSIX+SUS defined
in this case the behaviour is defined by more than one party (e.g.
usually at least two of { GNU *, FreeBSD, NetBSD, AST, MacOSX } ) which
gives a high probabilty of keeping these interfaces stable (that's the
reason why we jump directly to the ARC interface status "commited").
> And is this just the tip of the iceberg?
This is AFAIK offtopic for an ARC discussion... but the answer is both
"yes" and "no":
1. For now we only picked commands from libcmd which we already tested
(technically most of the code was already integrated as part of
ksh93-integration update1) extensively for compatibilty (this includes
POSIX+SUS test suites, multibyte tests, building
OS/Net+SFWNV+X11/FOX+KDE with the new commands, automated testcases for
each single CR# we fix etc.)
2. The next ARC case may contain a few more non-filesystem utilties
(e.g. "join", "head", "tail", "tee", "mkfifo") from libcmd and (as a
seperare ARC case) cover the remaining closed-source commands defined by
POSIX (e.g. "tr" in it's various incarnations, "printf", "od", "sed"
("tail" is already handled via the previous list) etc.)
3. The long-term plan is to create some kind of POSIX commands community
to actively develop (this includes that we try to push new developments
and technologies into the POSIX standard) and maintain these utilities -
see
http://mail.opensolaris.org/pipermail/ogb-discuss/2009-January/006302.html
for the original plan from last November (this has become even more
important now that Sun RIF'ed the complete team which was doing this
work for nearly a decade... ;-( )
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
