Darren J Moffat wrote:
> Other than the two issues in the Advice section I think this whole
> opinion is actually rather meaning less and provides no real guidance
> beyond what we already have in ARC and beyond what I believe the
> C-Teams do. Since there is no current plan (at least that I'm aware
> of) for a product or distribution that is pure 64 bit I don't see the
> point in the majority of the opinion, but then I didn't see the point
> in the case as presented either (because we never did see the answers
> to the performance impact questions). That is all really aside
> though it is what it is. All it really impacts is my vote. I don't
> disagree I just see the only value is in the advice section. So I
> don't know how to cast my vote.
>
> The two issues raised in the Advice section are very important ones.
>
> The first one (isaexec performance) needs some evidence it is too
> fluffy, the issue either exists or it doesn't, if it does then yes we
> need to fix it, if it doesn't then I don't see the point in the
> advice. Evidence required to support the advice.
As I wrote the advice, I based it on the assumption that bringing in the
code for isaexec, and then doing another exec, was itself not "cheap".
Taken with some small utilities which might be used "frequently" (how
many times does /bin/sh get spawned in a second on a busy system?), I
think the cost will add up. I've not done any measurements.
>
>
> The second issue is a vitally important one that impacts not just
> Solaris but all POSIX systems that provide a 32 bit application
> environment. It is Y2K all over again and what is worse "we" knew
> about this during all the Y2K work, but 2038 seemed such a long time
> way. This isn't an issue Solaris can fix alone but it is an area where
> I believe Solaris can propose a solution and present it to the
> appropriate standards bodies.
Yes. Was large file support a POSIX issue, though?
>
> I think unless the advise makes it clear that this is a standards
> issue that won't be known and the impact/scope of the project will not
> necessarily be understood by the recipients of the advice.
Hmmm... do you have specific language you'd like to add?
-- Garrett
>
> --
> Darren J Moffat
