> Date: Mon, 29 Jan 2007 23:40:22 +0100 > From: Roland Mainz <[EMAIL PROTECTED]> > X-Accept-Language: en > MIME-Version: 1.0 > To: Richard Lowe <[EMAIL PROTECTED]> > CC: ksh93-integration-discuss <[EMAIL PROTECTED]>, OpenSolaris Code mailing list <[email protected]>, April Chin <[EMAIL PROTECTED]> > Subject: Re: [osol-code] ksh93-integration prototype004 2007-01-27 webref+diff > Content-Transfer-Encoding: 7bit > > 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.
The diff file was an easy way to save the small set of differences between AT&T and OpenSolaris versions of the AT&T source files. The SCM can show the diffs between versions of one source base, but not AT&T vs. OpenSolaris source bases (at least not easily, without going through the exercise of mapping the corresponding versions and files). Hopefully the diff file makes it easier for an Open Solaris developer to update ksh93 in Open Solaris. > > 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". The ksh88 situation proliferated under a different environment. We do not intend to allow ksh93 in Open Solaris to diverge. > > 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 have tacitly agreed to the diff file, but if this is a source code no-no, is there a more appropriate place to store such a file? > > > 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
