>> If you need to move these utilities from SUNWesu to SUNWcsu, you will
>> need to get the on gatekeeper to deliver the following *ph file for you:
Sorry for missing this the first time but what is the justification for
moving any utilities into SUNWcsu? SUNWcsu needs to be broken up into
separa
> I'm leaning towards deleting the files first.
> Although we could do two commits on the first putback to save the
> unreferenced files under deleted_files/, I'm not sure
> if we want to keep doing this for subsequent putbacks, in cases where the
> set of deleted files may have changed. I think i
Roland,
> * Webrev over all non-AST files (this includes the files in
> usr/src/cmd/ast/msgcc/ by accident):
> http://www.nrubsig.org/people/gisburn/work/solaris/ksh93_integration/ksh93_integration_prototype005_webrev_20070606/non_ast_files/webrev/
Here are my comments for round "three":
usr/src
>> Lines 101-109 - As I indicated in an earlier review, I don't
>> believe this is necessary. Both Nevada and the Solaris 10
>> patch gate do large pages automatically (or so-called out of
>> the box) and so including these options is unnecessary.
>> However
> I am curious when (against which build) did you do your benchmarks and
> what sort of workload they consistent of?
Or even what sort of workload they consisted of. :-)
dsc
> FULL WEBREVS
> Non-AST files:
> http://cr.grommit.com/~chin/ksh93-webrev-jul13/jul13-nonattfiles
I only have one remaining comment.
usr/src/lib/libshell/common/tests/sun_solaris_getconf.sh
Line 32 - s/compatibilty/compatibility/
(I just happen to see that but otherwise did no
> These 35 built-ins will not be part of the namespace...there
> will not be a /usr/ast/bin directory nor any files.
> They will only be available in ksh93 as built-ins, which have
> pathname binding to /usr/ast/bin. This means that if these
> commands are called without a pathname prefix, the bui
> My understanding is that we do not need to include these built-ins in the
> ARC case, since they are not enabled by default.
> However, if we do include them in the case, we need to document them,
> and we did not intend to make this into a documented feature of ksh93.
By enabled by default, you
> Yes... and IMO it would be useless to document that because then
> everyone could step-up and demand the documentation of every single
> "easter egg" in ksh93, too. Currently the only purpose of these bits
I'm not sure if I want to even know what other sorts of "easter eggs"
might be present in
> Since getting a developer preview 2 machine on our lab network
> we noticed two things right away.
>
> 1. My shell initialization files produced error output now.
> (My default shell is /bin/sh)
>
> 2. Our Sun Studio testing shell scripts won't run anymore
>
> Is there a web page someplace wher
>> The best way is to log each of the separate issues as bugs in
>> defect.opensolaris.org.
>
> What category should I use for ksh compatibility issues?
Product: opensolaris
Component: software
>> The best way is to log each of the separate issues as bugs in
>> defect.opensolaris.org.
>
> What category should I use for ksh compatibility issues?
opensolaris/software should suffice.
dsc
>>> - 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".
>> I don't understand why this is necessa
> Umpf... part of the problem are exactly these "fixes". Originally the
Many of them are fixes for problems that were identified over the
years. Some of them might have been for standards, most of them I
suspect were due to customers escalating bugs against the shell. Since
Sun's ksh88 had long
Roland,
> Known issue. Solaris has the strict rule that we're not allowed to ship
> any *.so files if the API is not public, therefore we do not ship the
> *.so files. However some people may be interested to play around with
> the API (e.g. to build ksh93 plugins (builtin commands, functions etc.
> Unfortunately, SUNWastdev is in SUNWCdev -- it's intended to be
> delivered to customers who can't actually use it.
>
> Yes, in a better world, I think SUNWastdev is exactly where such bits
> would go.
I think SUNWastdev is the right place for these (or at least, the AST
related ones) and that S
Roland,
> Here comes round "two": I created a couple of webrevs in various
> flavours based on today's (2007-02-02) ksh93-integration sources. This
> isn't the "preliminary review request" (yet), just another attempt to
> provide an updated webrev.
> * Webrev over all files:
> http://www.nrubsig.
>> 1. How exactly are the Mamfiles used? Or is this just files
>> included with the ATT distribution for their build system.
>
> Yes, it's coming from the upstream sources... remember we don't want to
> fork() the upstream sources and that includes random stripping, file
> deletion
> 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).
> Currentl
Alan,
> I've made some fairly significant changes to perl in the process of
> integrating perl into Solaris. I've *never* added Sun copyrights as a
> result. I have legal approval to contribute to perl, and most of the
> contributions are really porting tweaks, so there's no IP that's worth
> AFAIK the only remaining question is whether the following change to the
> AT&T source file "builtins.c"
> (http://www.nrubsig.org/people/gisburn/work/solaris/ksh93_integration/ksh93_integration_prototype004_webrev_20070210/allfiles/webrev/usr/src/lib/libshell/common/data/builtins.c.html)
> requi
>> usr/src/lib/libc/port/regex/wordexp.c
>> Line 151 - Cstyle error - continuation lines should be indented
>> four spaces.
>
> Uhm... cstyle doesn't complain:
> -- snip --
> $ cstyle -P
> /home/gisburn/ksh93/on_build1/test1_x86/usr/src/lib/libc/port/regex/wordexp.c
> $ cstyle -p
>
>> 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 t
Bonnie,
> Re: adding a Sun copyright: there are no hard and fast rules. When working
> with third-party projects, we should try to adhere to the culture of that
> project. And often, copyrights are not added unless the change is deemed
> significant in terms of size or complexity. Most of th
> ... David (Comay): Are there any objections to leave the all the files
> in place and add a README for now describing the source file layout ?
I'm OK with this approach with dealing for the ATT files although it's
really unfortunate that unused Makefiles will be left in the source
directories, c
25 matches
Mail list logo
