David.Comay at Sun.COM wrote: > > >> For good reasons, you're > >> putting the libraries with the other libraries and at some point, it's > >> not clear if keeping the files which don't really serve a purpose as > >> documentation (at least for OpenSolaris.) Anyway, this is something > >> for you to work with the C-team on. > > > > Erm... I thought the reviewers have to decide that... or not ? > > Well, it is something that you work with your reviewers on but > eventually the C-team has the final call since they (or the CRT - the > Change Review Team) will make the final call on whether the project is > ready for integration.
Uhm... who does the normal code review ? The C-team ? Or a seperate set of reviewers (if "yes" we occupy gatekeepers, C-team and an unknown amount of reviewers. Or did I forgot anyone else ?) ? > In the case of this project, I'm OK with leaving the ATT files in the > source tree but I am concerned with some of the files such as the > Makefiles as one may reasonably assume they're part of the ON built > process when they're not. I'd almost suggest renaming them > Makefile.att or something like that but then, you're added to the work > you need to do each resync. What about Mike Kupfer's suggestion to add a README explaining the layout ? [snip] > >> Thanks for the pointers to the included Makefiles. Although I didn't > >> really see any ksh'isms in Makefile.libastl10n, > > > Uhm... small example: > > -- snip -- > > msgs/%.mso: ../common/%.c > > @mkdir -p "$$(dirname "$@")" > > @print "# Processing file $< to $@" >>msgcc.out > > @$(ASTMSGCC) -M-set=ast $(ASTMSGCCFLAGS) $(CFLAGS) $(CPPFLAGS) -c > > "$<" -o "$@" > > -- snip -- > > This uses: > > - $( command ) for subprocesses (instead of ` command `) > > - ksh "print" builtin > > - In the case of ksh93 "print", "dirname" and "mkdir" are builtin > > commands > > Okay but those are examples of where the existing, equivalent Bourne > Shell constructs are OK by me as is the fact that they aren't > builtins. > > I still would prefer to see it limited just to those Makefiles which > actually need it. It's difficult to "measure" in this case since you can theoretically rewrite everything to use plain bourne shell constructs if you have infinite time (and some desire for self-torture... =:-) ). > If that's the current state, then 'm OK with leaving > this in for the source directories being introduced by this project but > again, others may still have an issue. Umpf... I am going to write an proposal for that and submit it to gatekeepers (and I am praying to whatever Discworld god currently cares about programmers (Bel-Shamharoth ?) that this proposal gets a "thumbs up") ... [snip] > I'll try and go back to the original case but briefly, what's the > reason these were commited as Project Private interfaces if the intent > was to allow others to code to them? Please seperate the current SUNWastdev package from remaining parts of this putback. Currently the SUNWastdev package primarily contains l10n processing tools and some of them can be used to process l10n data created from ksh93 shell scripts. At least this part could (in theory) be used now. Anyway... as I said I have no strong feeling about this. I wish we could just place it at it's intended (permanent) location, even if it's currently only to make gatekeepers a little bit more happy, avoid future paperwork and <insert the 3rd reason I can't remeber anymore>. [snip] > > /usr/bin/sparcv9/ksh93 removed because "isaexec&&magical builds" isn't > > done yet (yes, I know.. you wrote personally vs. delivering what was > > specified in the two ARC cases)) that getting things implemented/putback > > in the wrong order may affect the project progress by adding even more > > paperwork or forcing a serialisation of project operations to make sure > > that one step creates all building blocks for the next case (instead of > > doing the work in parallel and even build on top of things which may > > only be available after the putback). Yes... I am aware that engineering > > may prefer to have paperwork and all things in place (as someone else > > said here... it may always happen that the engineer working on this > > stuff gets run over by a truck etc.) but I am not sure whether this > > should be mandatory for a "feature putback" like ksh93 or the > > "SUNWastdev" package. > > Actually, I think it's even more important for something which > constitutes a feature, particularly one with an obvious API. If it's > there and available, people will begin to program to it and a "shell > API" seems like a much more inviting target than shall we say, some > kernel API. That's why I think it's even more important we get this > correct for now and then make the incremental changes later. Erm, Ok... but maybe our definition of "correct" differs here (e.g. I think it's "correct" to ship the 32bit ksh93 parts even on SPARC now) ... or not ? > >> I guess I'm wondering though what sort of release values are used with > >> other systems? Could it instead be based on something like (major # * > >> 100) + (minor #?) > > > > In any case this would AFAIK require major changes in the upstream > > sources (and we try to not fork() the code, remember ?) because AST is a > > large codebase (ksh93 is only a tiny piece). It's possible to change but > > it may require some time (the problem is that this value comes from the > > base architecture directory (e.g. if you build the upstream package the > > generated binaries and includes are stored in > > arch/<value>/(bin|include/ast|libs|etc)/ where <value> matches the value > > we're currently talking about) and I am not sure which code depend on > > this (we're talking of a codebase which matches OS/Net in size) ...) ... > > Sorry, I still don't quite understand those the difference between > using both components or just the minor part since in the ends it's > just a number that appears after the "sol" part, right? See Glenn's email about the issue. Basically it's the practiacally/pragmatically assumtion that right now only the "minor version"-part is used in Solaris. > However, if the ATT code already expects this to be "11" for a SunOS > "5.11" version, then I'm fine with what you have now. If you could > pass upstream the feedback, though, that this could break if the minor > part ever reverts to "0", that would be appreciated. That's currently under discussion... however I would really prefer to forward any change in this area to after this putback because it affects the whole AST codebase - ksh93 is only a tiny bit of it. Right now it doesn't hurt anyone and something like SunOS 6.x is many years away. [snip] > >>>>>> usr/src/lib/libshell/misc/buildksh93.ksh > >>>>>> usr/src/lib/libshell/misc/buildksh93.readme > >> > >>>> Or is the script that's used to generate the files which are eventually > >>>> *checked in* to ON? > >>> > >>> Right. Please read the script and look at the original AST build system > >>> now it works - "buildksh93.ksh" does some "modifications" to the build > >>> setup to make sure we find some features in libraries which are normally > >>> not detected automatically and enforce things like XPG6/C99 to avoid the > >>> limitations of a normal build (which both dramatically affects > >>> performance and other details). > >>> BTW: "perl" in OS/Net does the same - see > >>> http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-February/002244.html > >> > >> Yes, and I'm not sure if for that reason Perl really belongs in ON > >> either :-) but I understand you're following that precedent. > > > > Ok... does that mean you're no longer demanding to see the head of > > "buildksh93.ksh" on a stick in front of your office (instead of being > > part of this putback) ? :-) > > I guess that's one way of putting it. I don't think the files belong > in ON Well, "perl" in OS/Net does the same for (AFAIK) the same reason. In my case I am very worried to shoot myself into my feet by eithe loosing the script (Ok, worst case scenario) or using the wrong version of the script on the wrong upstream sources. Therefore I'd like to see it in the same source control repository as the main sources as both more or less work together. IMO it's better to have too many files in the tree than lacking some important bits and then spend many hours to hunt down old bugs which are triggered by using the wrong version of the script (IMO another economical issue for me - I'd like to spend working on the real code and not seeking new and innovative ways to introduce regressions... :-) ). > but I'm not going to lie down on the train tracks over this > issue. Thanks! :-) [snip] > >>> No, the idea was to implement Sun-Bug #6474270 ("isaexec and magical > >>> builds") and set an environment variable which tells isaexec which ISA > >>> should be used. I was hoping to get this work done in parallel but > >>> somehow the request is still waiting in the request-sponsor list (see > >>> http://opensolaris.org/os/bug_reports/request_sponsor/) ... ;-( > >> > >> But that hasn't been implemented yet so it seems including the sparcv7 > >> version at this time is premature. > > > > Umpf... what can I do in this case ? in a perfect world where > > "isaexec&&magical builds" would already be "done" we would not have this > > discussion, right ? > > But such a world doesn't yet exist. And it seems the change required > to go from a 64-bit only ksh93 on SPARC to both versions being included > is trivial. Or perhaps I'm missing something. See below... [snip] > > this really neccesary ? The 32bit libs are needed soon by > > "shcomp", "sleep" and all the things which currently use "alias.sh". And > > the 32bit executable which sits in /usr/bin/sparcv7/ksh93 is just a > > wrapper which calls directly into libshell.so using something more or > > less like |int main(int ac, char *av) { return sh_main(ac, av); }| - the > > stripped binary is around 7k - which is smaller than this email. > > I'm not trying to be difficult - really. ;-) But it seems delivering > those 32-bit objects on SPARC at the same time as delivering those > other builtins make sense to me. Problem is that we do not know how long this will take and in which order any followup projects will happen. AFAIK ARC cases, code review and putbacks for multiple (sub-)projects/followups will likely not run with the same speed and I'd like to avoid having any "interlocks" betweek followups after this putback - it would only require more waiting (and I am not good at waiting and I guess it scratches on other people nerves, too). > Like the earlier feedback that > delivering the various new libraries under /lib was premature, Well, I am not sure. We did not had any good example code or could reference future consumers which need it and the original RFE for ksh93 did not cover /sbin and the "feature" to deliver a 32bit version of ksh93 to /sbin was added quite late based on community requests so I didn't really care about this part. However I am not really happy about this because it closed the door to gather any compatibilty data from OpenSolaris-based distributions who may want to exploit using ksh93 as /sbin/sh (based on earlier testing it works without problems but any "/sbin/sh to ksh93 migration"-project will IMO have to provide real-world data which the OS/Net version of ksh93 will no longer be able to produce - the matching build switches have been removed from Makefile.ksh93switch and I won't try to fight for it a second time). > I also > think delivering the 32-bit components on SPARC is premature and easily > remedied when you introduce those 32-bit builtins. Umpf... I have to disagree in this case. IMO it's better to deliver them now instead of creating such kinds of "interlocks" for any follow-up projects. Maybe it's different for people within Sun but I think that for external people it may only cause lots of waiting. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
