>> 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. 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. Others may have a different opinion. >> 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. 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. >> By internal, it would be built as part of the ON build process but it >> would not be included at this time in the WOS. When you install >> Nevada, you wouldn't see the package installed on the system. However, >> it would be available for those with ON build machines. > > How would normal developers get that package ? I'd like to avoid that we > force gatekeepers to bundle it with "SUNWonbld" and then change that > again after a few months. That only generates unneccesary work... We do this with many other packages for the appropriate "consumers". For example, the Install consolidation requires access to the private libzonecfg library and corresponding header files. Those components are available in the SUNWzoneint package and they have an approved PSARC contract with the Zones project team in order to get those packages. When we designed those libzonecfg interfaces, we realized that 1) they weren't ready for other consumers and 2) they were likely to change in the future. As such, we decided to hold off making them public even though there was a lot of interest in them (people get tired of calling zonecfg(1M) or zoneadm(1M) using system/popen directly from their C programs!) The same could be done for SUNWastdev as well. The fact is that under the commitment level that these interfaces were ARC'ed at - or more precisely, the underlying libraries - they should not be consumed by users other than those within the consolidation itself. Look, I'm all for raising the commitment level of these libraries if it makes sense. But what I don't agree with is including pieces of software in the product which might change or be removed. 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? >> When the commitment level of the required interfaces in libshell, etc >> are raised, you wouldn't need to move any components but rather add in >> the *.so links and the lint libraries. >> >> The amount of so-called paperwork is minimal - besides a PSARC >> fast-track, there is a short ASCII form called a "package RTI" that >> tells the Solaris Release Engineering group to include this package and >> which meta-cluster is appears in. > > Even the "minimal" paperwork needs time. It may be easier for people > within Sun but for people outside Sun we're talking about weeks up to > months of waiting. And it seems (based on your request to get I really do sympathize with you on this point and we're doing the best we can to get this stuff moving quicker, more of the processes pushed outside the firewall, etc. > /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. >> 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? 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. >>>> I didn't explain my question well. Are you planning on moving >>>> usr/src/lib/libcmd/common/mapfile-vers to >>>> usr/src/lib/libcmd/mapfile-vers and updating the file? Perhaps this is >>>> a question for April since it's a Teamware operation. >>> >>> Erm, yes. I am following the suggestion of Roger Faulkner (if I recall >>> the name correctly) who suggested to put the files in the base >>> directory. At least the following libraries do it the same way (this is >>> from our B51 tree): >> >> Well if Roger has reviewed this and signed off on it, then I'm happy. >> :-) > > See > http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-August/000782.html > Is that enougth ? Yes, that's excellent. Thanks for the pointer. >>>>>> 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 but I'm not going to lie down on the train tracks over this issue. >>>>>> usr/src/pkgdefs/SUNWcsu/prototype_sparc >>>>>> >>>>>> Lines 50-51 - What is the reason for shipping a 32-bit version >>>>>> on SPARC? Can ksh93 be used to read 32-bit core files or >>>>>> processes? :-) >>>>> >>>>> There are several reasons including: >>>>> - ksh93 supports (loadable) binary plugins which may itself rely on >>>>> other shared libraries which may not be available as 64bit versions. In >>>>> those cases a 32bit ksh93 is needed. I am waiting for a sponsor for >>>>> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270 >>>>> ("isaexec and magical builds") (see request-sponsor queue) to make >>>>> "isaexec" adjustable for applications which need such a functionality >>>>> (via restricting the list of ISAs based on accept and/or reject filter >>>>> environment variables). >>>> >>>> So how does a SPARC user use ksh93 in that case? Do they code their >>>> scripts to use /usr/bin/sparcv7/ksh93 directly? >>> >>> 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. >>> Well, we heavily stripped the original ARC case to make the first >>> putback self-contained, e.g. it should not affect anything else except >>> adding ksh93+libraries (we even stripped "shcomp" since it would deliver >>> a new kernel module (to recognize compiled shell code (similar to >>> javaexec))) - but ARC 2006/550 specifies these files and the usage of >>> isaexec (from >>> http://www.opensolaris.org/os/community/arc/testbed/caselog/2006/550/onepager/): >>> -- snip -- >>> Interface Description >>> --------- ----------- >>> /usr/bin/ksh93 the korn shell >>> /usr/bin/pfksh93 profile shell >>> /usr/bin/rksh93 restricted shell >>> >>> which will be hard links to /usr/lib/isaexec; isaexec will execute >>> the corresponding 32-bit binary in /usr/bin/{sparcv7,i86} or >>> the 64-bit binary/usr/bin/{sparcv9,amd64}, depending on the >>> architecture. >>> The isaexec links will allow the 64-bit version of ksh93 >>> to be executed by default on 64-bit platforms. >>> -- snip -- >>> As I said this is done intentional, even on SPARC (Garret bickered >>> already about the use of isaexec... ;-( ) ... >>> ... you're not coming up with the argumentation that we have to remove >>> parts which are not in use yet and re-add them later with the part which >>> starts using it, right ? >> >> Actually, I am arguing for delivering what was specified in the two >> PSARC cases and nothing else at this time. It's not a huge thing >> delivering the 32-bit version on SPARC but it's unnecessary at this >> time. Personally, I would rather see just the 64-bit version delivered >> at this time (yes, using isaexec just as we do with many 64-bit only >> SPARC deliverables) and then deliver the 32-bit version when the new >> plugins arrive. > > Umpf... is 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. Like the earlier feedback that delivering the various new libraries under /lib was premature, I also think delivering the 32-bit components on SPARC is premature and easily remedied when you introduce those 32-bit builtins. Again, that's simply my opinion. Others may feel differently. I suppose that I'm a "struct constructionist" when it comes to these things (see http://en.wikipedia.org/wiki/Strict_Constructionist) although I never thought I would characterize it that way. dsc
