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
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
