Richard Lowe wrote:
> Roland Mainz wrote:
> > Hi!
> > I created a couple of webrevs in various flavours based on today's
> > ksh93-integration sources. This isn't the "reliminary review request"
> > (yet; the official rquest should come on ~~ monday or tuesday), just an
> > attempt to provide an updated webrev.
>
> I'm yet to look in any detail at the webrevs, but most of the comments I had
> from looking at diffs prior to this are covered in your notes, so I'll
> comment on them.
Ok...
> > ** Notes:
> > - All AST sources are in usr/src/lib/lib(ast|pp|dll|cmd|shell)/common/
> > and usr/src/cmd/ast/. All files are 100% identical with the upstream
> > (AT&T) versions except those listed in
> > "usr/src/lib/libshell/misc/ksh93_solaris_builtin_patch.diff".
> > ####----> All changes to the upstream sources ====> MUST BE <==== stored
> > in *.diff files (and a README per *.diff) in usr/src/lib/libshell/misc/
> > to make sure they can be backed-out and re-applied when the AST sources
> > in the OS/Net tree get updated (e.g. the usual update procedure works
> > like this: diff old and new upstream sources, backout the diffs from
> > usr/src/lib/libshell/misc/*.diff from the OS/Net tree, apply diffs from
> > upstream, reapply diffs from usr/src/lib/libshell/misc/*.diff, refresh
> > files in usr/src/lib/lib(ast|pp|dll|cmd|shell)/(${MACH32}|${MACH64})/
> > from a native AST build).
>
> I don't understand why this is necessary, the SCM will provide you with
> diffs and their associated comments.
And how can I back the changes out when I do not have access to the SCM
? Right now there is no way to do such a thing and even the Mercurial
support in the OpenSolaris OS/Net tree is in it's infancy (or it looks
for someone working outside the group who is working on that part of
OpenSolaris) and I don't see a plan how Mercurial can protect us from
running into great trouble (as outlined below).
AFAIK there are at least two justifications for such a *.diff:
1. The old ksh88 in the Solaris tree was hacked to death in various bad
ways, making it impossible to track changes without causing potential
harm for older bugfixes. AFAIK Sun has a SCM for those sources but
somehow this failed to work. IMHO such a policy is mandatory to prevent
current and future maintainers to play around with the codebase randomly
and causing it to diverge from the upstream sources which may result (in
the worst case) incompatibilities between our version of ksh93 and the
upstream version. THIS MUST NOT HAPPEN AGAIN!! And yes, I am trying to
be adamant in this case since I do not want to see the ksh93 in Solaris
fall into pieces like it happened with the old /usr/bin/ksh. We really
need an additional safeguard. The whole ksh93-integration project uses
interoperabilty as it's foundation, that's why we had all the main other
many months over three ARC cases to get it "right".
2. We'd like to update many many times, keeping ksh93 in Solaris in sync
with the upstream development. This will likely result in half a dozend
or more updates per year and a seperate patch which tracks the
Solaris-specific changes is very usefull to back them out between
updates (without having to mess around with a SCM; the update procedure
should IMHO be completely SCM independant). It also allows tight control
over Solaris-specific changes to the AST/ksh93 codebase. In theory all
patches should be submitted to upstream, NOT to the Solaris codebase.
The *.diff policy should remind maintainers that changes should go
through upstream and then make it into Solaris with the next source
update from upstream.
> > Anyone who is patching files in
> > usr/src/lib/lib(ast|pp|dll|cmd|shell)/common/ and usr/src/cmd/ast/
> > without storing diffs+READMEs in usr/src/lib/libshell/misc/*.diff will
> > be <insert-some-horrible-torture-here (gatekeepers should decide how the
> > punishment should look like... I'd suggest the usage of deep pits filled
> > with komodo dragons, hot iron, boilling acid etc. (in random order))>.
>
> Has this diff dance actually been agreed upon by anyone?
April: ping!
> I'd like to see an
> explanation of why you can't just use the SCM to fulfill your needs. (I can
> accept one may exist, I just don't see what it is...)
See above. Basically I do not want to see that ksh93 in Solaris sufferes
the fate of the old /usr/bin/ksh. Somehow Solaris-specfic changes should
be kept at the smallest possible minimum level (and I am already not
very happy (or better: grouchy) about the cut-down list of builtins but
accept this as a oblation to Solaris's backward-compatibilty policy. But
it still hurts me... ;-( ).
[snip]
> > - usr/src/lib/lib(ast|pp|dll|cmd|shell)/Makefile.com list "-erroff="
> > flags per object file, not globally, resulting in lists which look
> > "huge" because we list each appeance of a suppressed warning explicitly
> > including a comment (and "yes", we're working on reducing the list, step
> > by step).
>
> I don't see why this can't be done prior to putback, beyond your aversion to
> deviating *at all* from the upstream sources. I'd far prefer to see these
> lists empty prior to putback, even if upstream haven't accepted patches (yet).
Grumpf... we already did many fixes in this area. We're down from nearly
1600 warnings down to this list (which is tiny compared to other parts
in OS/Net. And AFAIK we're even the only project which handles the
warnings per object file including comments and not globally which
results in a list larger than usual). The remaining issues are usually
tricky issues. Rememeber these sources have to compile and run on more
than 40 platforms and not every compiler likes any workaround which
means changes in this area have to be done with great care.
Another set of problems comes from issues in the Solaris includes, for
example there is a problem with <sys/mman.h> which appears to have
problems with C99/XPG6 - the |madvise()| macros (|MADV_*|/co.) are
defined but the |madvise()| prototype is obmitted. AFAIK the correct
solution is to fix the Solaris includes, not the AST sources.
At the end of the scale there are things like |#pragma| which are used
by the AST sources but not recognized by the Sun Workshop/Forte/Studio
compiler, AFAIK this will one -erroff= switch which will remain for all
eternity.
Finally... we're working on getting the remaining issues killed from the
tree if technicially possible and reasonable. But at some point we
should do a putback, even with these tiny fraction of problems
remaining. We're now scrubbing nearly a year over all the issues (trying
to create something like a "perfect putback" (which doesn't exist in
reality (unless someone invents a way to spend infinite time on an
infinite number of problems))) and I don't want to spend yet another
year tweaking any -erroff= flags. IMHO there are MUCH worse things in
the tree (both OS/Net in general and ksh93) we have to address first...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
