In the case of the Mamfiles it's IMO "documentation". We check-in these
files and keep them updated to have a reference point for the matching
OS/Net Makfiles. I know that this is not perfect but it's at least
economical for those who work on the current tree (e.g. April and me).
Currently we can deploy updates within less than an hour (excluding
testing and a full OS/Net build) and randomly removing files will only
cost more time since the more or less automated procedure will no longer
work and then patches need to be applied by hand which takes far longer.
But for many others, it's just cruft in the gate. I definitely could
understand it if the source directory was being dropped in situ into
the source base but that's not the case here. 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.
I'm not trying to reopen this ON-versus-SFW debate here but the
discussion around these files is precisely because you're trying to
integrate this into ON. Consolidations such as SFW work much more in a
pass-through mode - the source comes from upstream, undergoes a small
amount of change (if any at all) and then is compiled and packaged via
some sort of mechanism (perhaps a Sun-supplied master Makefile and the
open source project's own ./configure script).
Grumpf... part of the decision to put ksh93 into OS/Net is that it is
(or better: should be) the successor of the old korn shell which was in
OS/Net, too. We'd like to run the work under the same rules to make sure
noone can throw the "(shell-)flavor of the day"-stones after us once we
run the ARC case for the "/usr/bin/ksh to ksh93"-migration.
Please understand that there really is no correlation here. I can
understand wanting from an aesthetic point of viewing delivering ksh93
through the same consolidation as the Sun ksh88 but it doesn't have to
be the case. Even delivering it via SUNWcsu isn't really necessary
because other packages can be designated as "core packages" (in this
case, we're talking about the Sun branded Solaris distribution and your
mileage may vary with other packaging systems and distributions.)
In any case as I said, I'm not trying to reopen that decision but
rather point out that some of the difficulty we're having here is
because ksh93 is more in keeping with other source that comes from an
external/upstream community.
That certainly is a good argument if bourne shell implementation is
unreadable. But there seem to be some Makefiles where I didn't see any
ksh93 constructs at all, or minimal ones at that. For example, why the
changes to libcmd's Makefiles to use /bin/ksh?
Because libcmd's Makefile "include"s things like "Makefile.libastl10n"
and "Makefile.astinclude". I know that this functionality could be
re-done using SHELL=/bin/sh which then calls scripts which use
"#!/usr/bin/ksh" and do the same job - the question is whether this is
really neccesary when the same could be done in the Makefile's itself
with less effort.
Thanks for the pointers to the included Makefiles. Although I didn't
really see any ksh'isms in Makefile.libastl10n, I did noticed them in
Makefile.astinclude.
3. With respect to the *.so library links and the the lint
library, I think including these in an internal package is fine
but I do not believe they should be actually included in any
metacluster at this time. From my understanding of the
contents of the SUNWastdev packages, that also holds true for
it as well.
Erm, the primary purpose of the "SUNWastdev" package is to deliver AST
development tools to /usr/ast/bin/. It was not intended to become a
dumping ground for everything.
Thanks for the explanation. I went back to PSARC 2007/035 and it does
seem that this package should contain just the components presented in
that case.
Did you read the explanation what the "SUNWastdev" package is used for
in the future ?
Yes I did, but the future is just that - it's something that we expect
and hope will take place but it hasn't yet. This is especially
important with exposing interfaces which we don't wish to make
available yet. We should not be exposing things which are likely to
cause confusion or brokenness until our "commitment" to them (hence the
notion of an "ARC commitment level") has risen to the appropriate
level. In the case of SUNWastdev, although it's contents are currently
at Volatile, there are necessary dependencies that are at a lower
commitment level so actually including this package in the WOS seems
premature to me.
But I do have one question for SUNWastdev. If the *.so library links
for libshell, libast, libdll, and libcmd (and libpp, for that matter)
are not supplied, is this package actually usable by anyone? Let's
leave out the ON developers but rather focus on the end-developer who
is wishing to use the AST development tools. Do these tools depend on
linking against the currently project private libraries?
Yes, they link against libast and some against libpp.
Put another
way, should this package me an internal-only package right now because
the end-developer cannot use it given the commitment level that was
ARCed?
What do you mean with "internal-only package" ? And see my question
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.
above about the future target of the package (like the other ksh93 and
AST components we'd like to put them into their correct places from the
beginning... anything else (like moving files etc. around) will just
generate more paperwork which will consume much time (at least I am a
volunteer and (unfortunately) have to work for food on other stuff
(which means I don't like to spend time on paperwork unless it's really
mandatory))).
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.
Do add a Sun copyright to files which have a significant
change. The definition of the latter is sometimes hard to
define but changing it to make it compile or work under
OpenSolaris clearly falls in the "add" category. In any case,
please check with Bonnie.
What about a file where we added an |#include|-statement to include
another (CDDL-)licensed chunk of code ? The |#include|-solution was used
to avoid the situation that we have to add a license template to the
AT&T sources...
In my opinion, you still would add a Sun copyright in this case but
please ask Bonnie Corwin - she's the right OpenSolaris person to
clarify the situation.
usr/src/lib/libast/amd64/Makefile
Line 31 - Is there a reason you're only using the minor part
here rather than the whole $(RELEASE) string? Is there some
standard here that ksh93 uses with different OS versions?
See may reply to James Carlson's email
(http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-February/002225.html).
Basically the upstream code uses this as a platform identifer and we use
the same algorithm to provide the same value in this case (the code
doesn't build without a value and I don't want to pass a hardcoded
value).
I saw the response but it still sems short-sighted on including part of
the `uname -r` value but not the rest.
Erm, what should I do in this case ? We can't really add a random value
here. I am just emulating the behaviour of the upstream build (without
hardcoding values).
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 #?)
What happens if we ever produce
a SunOS 6.0?
I hope you'll call it "Solaris" then and drop the SunOS part (yes, yes,
I know... SunOS = core OS, Solaris = whole product) ... :-)
Solaris is a marketing name for Sun's branded distribution. The actual
OS component is SunOS. :-)
usr/src/lib/libcmd/common/mapfile-vers
This is showing up only under "Old". Are you removing it?
"mapfile-vers" should be in the libraries's base directory to avoid that
this may get lost during source updates. The common/ subdir should for
the upstream sources only (only exception is the additions to the demo
code and test suite (e.g. the test to watch over the getconf
compatibilty (usr/demo/ksh/tests/sun_solaris_getconf.sh)) ).
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.
:-)
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.
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.
BTW, what is the API for creating those binary plugins? Is it an open
API as covered by the PSARC case?
Uhm... yes and no. The ksh93(1) manual page describes the usage but
doesn't go into all the details. Basically the prototype is
|b_<name_of_command>(int ac, char *av[], void *context);|. Simple
commands can work with that while more complex ones which depend on
modifying the shell's state have to access |context| (which is a
|Shell_t *|) and the libshell API which uses |Shell_t *| as arguments is
not ARC'ed.
- We need libshell&co. around for future consumers like the various
tools currently wrapped in "alias.sh" (this includes things like
/usr/bin/test etc.), "shcomp" (shell script compiler), /usr/bin/sleep
(using a 64bit binary for this is IMO an overkill), /usr/bin/printf etc.
and obmitting the 32bit shell would not be wise in this case (for
example: how else can we test the libraries then ?).
Yes, but those components are not part of this case, correct?
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.
dsc
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
