From plocher@sac.sfbay.sun.com Fri May 30 08:45:06 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UFj6Ms026790 for ; Fri, 30 May 2008 08:45:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4UFj4Wn020134; Fri, 30 May 2008 08:45:06 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1O00F0DUF30W00@nwk-avmta-2.sfbay.sun.com>; Fri, 30 May 2008 08:45:03 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1O00AATUF1WN70@nwk-avmta-2.sfbay.sun.com>; Fri, 30 May 2008 08:45:01 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4UFj1st008791; Fri, 30 May 2008 08:45:01 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UFixjA026764; Fri, 30 May 2008 08:44:59 -0700 (PDT) Received: (from plocher@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m4UFix3n026760; Fri, 30 May 2008 08:44:59 -0700 (PDT) Date: Fri, 30 May 2008 08:44:59 -0700 (PDT) From: John Plocher Subject: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] To: PSARC-ext@sun.com Message-id: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 869 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Switch SPARC GNU coreutils+bash from 32 to 64bit 1.2. Name of Document Author/Supplier: Author: Roland Mainz 1.3 Date of This Document: 30 May, 2008 4. Technical Description gisburn: Does it require an ARC case if we switch the GNU coreutils from 32bit to 64bit on SPARC only (no changes in interfaces and delivered files)? plocher: It doesn't sound like this has any architectural implications... gisburn: Not that I am aware of. plocher: so, I'd say that this was the entire arc review :-) 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From jek3@sun.com Fri May 30 11:13:04 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UID3gB004687 for ; Fri, 30 May 2008 11:13:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4UICuUQ003116 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 May 2008 11:13:03 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P0050Z19R6A00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 12:13:03 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P002KX19QZQ40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 12:13:02 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m4UID189212272; Fri, 30 May 2008 11:13:02 -0700 (PDT) Date: Fri, 30 May 2008 08:15:13 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> To: John Plocher Cc: PSARC-ext@sun.com Message-id: <48404431.9010701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1701 John Plocher wrote: > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Switch SPARC GNU coreutils+bash from 32 to 64bit > 1.2. Name of Document Author/Supplier: > Author: Roland Mainz > 1.3 Date of This Document: > 30 May, 2008 > 4. Technical Description > > gisburn: Does it require an ARC case if we switch the GNU coreutils > from 32bit to 64bit on SPARC only (no changes in interfaces and > delivered files)? > plocher: It doesn't sound like this has any architectural implications... > gisburn: Not that I am aware of. > plocher: so, I'd say that this was the entire arc review :-) > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > SFW > 6.5. ARC review type: Automatic > 6.6. ARC Exposure: open > Sorry, I want a fast-track. 1) I believe this is an incomplete project. What's good for GNU coreutils is also good for the rest of the utilities. The source of the utilities doesn't matter. Project completeness is always an arc concern. 2) We have a 32-bit user land (only) because 32-bit utilities on SPARC weren't any faster than 64-bits (so why support both?). Since we have unsupported any 32-bit SPARC hardware, the change could be made now. However, validation needs to be done that this doesn't result in performance regression. (Should be faster on an x86 - its all about the number of registers, not the data path.) This is a C-team (PAC?) issue, but it should be considered. - jek3 From John.Plocher@sun.com Fri May 30 11:48:07 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UIm6wp006782 for ; Fri, 30 May 2008 11:48:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4UIlrSE005672 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 May 2008 19:48:06 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00M052W4E800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 11:48:04 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00KPO2W4V520@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 11:48:04 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4UIm4eK000413 for ; Fri, 30 May 2008 11:48:04 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1P003012LX9700@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 11:48:04 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1P00AJ72W2WY70@fe-sfbay-09.sun.com>; Fri, 30 May 2008 11:48:02 -0700 (PDT) Date: Fri, 30 May 2008 11:48:02 -0700 From: John Plocher Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48404431.9010701@sun.com> Sender: John.Plocher@sun.com To: Joseph Kowalski Cc: John Plocher , PSARC-ext@sun.com Message-id: <48404BE2.4060207@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 1482 Joseph Kowalski wrote: > Sorry, I want a fast-track. What are the architectural (as opposed to C-Team, Design or RE) issues? > > 1) I believe this is an incomplete project. This sounds to me like "go boil the ocean" scope creep. Roland has identified several utilities that would benefit from being 64 bit on 64 bit OSs, and is willing to do the work to "convert" them. The architecture to "convert" utilities already exists, and is applicable to anyone else who wants to do the work. And, while it may be a C-Team issue whether this work is done via isaexec()or via a makefile change, there is already a mix on SPARC in /usr/bin: fumount: ELF 64-bit MSB executable SPARCV9 ... nsrib: ELF 64-bit MSB executable SPARCV9 ... nsriba: ELF 64-bit MSB executable SPARCV9 ... If Roland was doing something that created/changed the architecture such that other things couldn't be converted, then I'd agree with you, but to say that he must invest additional/unbounded time to investigate "converting" all the other utilities shows a fundamental misunderstanding of how a volunteer open source community works. > 2) We have a 32-bit user land (only) because 32-bit utilities on SPARC > weren't any faster than 64-bits (so why support both?). In this case, the 32 bit versions have capacity limits that are affecting Roland and he wishes to remove those limits. This is not at all a performance issue, but a make it work better one. -John From jek3@sun.com Fri May 30 12:22:37 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UJMbIj008767 for ; Fri, 30 May 2008 12:22:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4UJMaFl001792; Fri, 30 May 2008 12:22:37 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P000074HOOY00@nwk-avmta-2.sfbay.sun.com>; Fri, 30 May 2008 12:22:36 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00K9Z4HNUY40@nwk-avmta-2.sfbay.sun.com>; Fri, 30 May 2008 12:22:35 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m4UJMYc7223267; Fri, 30 May 2008 12:22:34 -0700 (PDT) Date: Fri, 30 May 2008 09:24:46 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48404BE2.4060207@Sun.Com> To: John Plocher Cc: John Plocher , PSARC-ext@sun.com Message-id: <4840547E.70202@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Bfz5LwuK0uOzvvSNEGGCrw)" X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 8504 This is a multi-part message in MIME format. --Boundary_(ID_Bfz5LwuK0uOzvvSNEGGCrw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT John Plocher wrote: > Joseph Kowalski wrote: >> Sorry, I want a fast-track. > > What are the architectural (as opposed to C-Team, Design or RE) issues? >> >> 1) I believe this is an incomplete project. > > This sounds to me like "go boil the ocean" scope creep. Sometimes the burners need to be turned on. > > Roland has identified several utilities that would benefit from > being 64 bit on 64 bit OSs, and is willing to do the work to > "convert" them. OK. Then he (you) should do a "self review" for those specific items. I don't see why /usr/gnu/bin/awk should get preference over /usr/bin/awk just because its in gnucore. > The architecture to "convert" utilities already exists, and is > applicable to anyone else who wants to do the work. And, while it > may be a C-Team issue whether this work is done via isaexec()or via > a makefile change, there is already a mix on SPARC in /usr/bin: > > fumount: ELF 64-bit MSB executable SPARCV9 ... > nsrib: ELF 64-bit MSB executable SPARCV9 ... > nsriba: ELF 64-bit MSB executable SPARCV9 ... Humm,... maybe,... but these just sound like bugs. (In the case of fumount I'm going to check who did this. It's rather strange that somebody actually went to the effort to change this.) > If Roland was doing something that created/changed the architecture > such that other things couldn't be converted, then I'd agree with > you, but to say that he must invest additional/unbounded time to > investigate "converting" all the other utilities shows a fundamental > misunderstanding of how a volunteer open source community works. Let's use this fast-track to clarify the requirement/expectation. Speaking of how a "volunteer open *source* community works", this is a proposal about how a *binary* distribution should be constructed. This is Sun's decision or a decision about a future OpenSolaris reference distribution. Tell me again how a volunteer makes this distribution configuration decision. I'll place my *opinion* about how "a volunteer open source community works" against your *opinion* any time. Please don't be condescending from a high perch. In particular, for any example of a "how a community works", a counter example can be found. Generalizations aren't usually appropriate. Just FYI, if the Apache folk were to get a request like this, I'd place $$$ that they would reject it (but it is a guess). All communities have oversight - just the titles and the process differ. Heck, in OpenSolaris, we have a majority vote (by a small group). In Apache, if 2 members (of a small group) say "no", its dead. >> 2) We have a 32-bit user land (only) because 32-bit utilities on SPARC >> weren't any faster than 64-bits (so why support both?). > > In this case, the 32 bit versions have capacity limits that are > affecting Roland and he wishes to remove those limits. This > is not at all a performance issue, but a make it work better one. Back to my awk example, if the problem is in /usr/gnu/bin/awk, it seems very poor form (and a source of "huh?" bugs) to not make the equivalent change to /usr/bin/awk. Then again, since we can't make these changes for x86, these seems like an even worse idea - "CR 6999999: awk works on sparc, but not on x86". Anyway, I've asked that this become a fast-track. Please make it so. - jek3 --Boundary_(ID_Bfz5LwuK0uOzvvSNEGGCrw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT John Plocher wrote:
Joseph Kowalski wrote:
Sorry, I want a fast-track.

What are the architectural (as opposed to C-Team, Design or RE) issues?

1)   I believe this is an incomplete project.

This sounds to me like "go boil the ocean" scope creep.

Sometimes the burners need to be turned on.


Roland has identified several utilities that would benefit from
being 64 bit on 64 bit OSs, and is willing to do the work to
"convert" them.

OK.

Then he (you) should do a "self review" for those specific items.

I don't see why /usr/gnu/bin/awk should get preference over /usr/bin/awk
just because its in gnucore.

The architecture to "convert" utilities already exists, and is
applicable to anyone else who wants to do the work.  And, while it
may be a C-Team issue whether this work is done via isaexec()or via
a makefile change, there is already a mix on SPARC in /usr/bin:

fumount:        ELF 64-bit MSB executable SPARCV9 ...
nsrib:          ELF 64-bit MSB executable SPARCV9 ...
nsriba:         ELF 64-bit MSB executable SPARCV9 ...

Humm,... maybe,... but these just sound like bugs.  (In the case
of fumount I'm going to check who did this.  It's rather strange
that somebody actually went to the effort to change this.)

If Roland was doing something that created/changed the architecture
such that other things couldn't be converted, then I'd agree with
you, but to say that he must invest additional/unbounded time to
investigate "converting" all the other utilities shows a fundamental
misunderstanding of how a volunteer open source community works.

Let's use this fast-track to clarify the requirement/expectation.

Speaking of how a "volunteer open source community works",
this is a proposal about how a binary distribution should be constructed.
This is Sun's decision or a decision about a future OpenSolaris
reference distribution.  Tell me again how a volunteer makes this
distribution configuration decision.

<I'm very annoyed>

I'll place my opinion about how "a volunteer open source
community works" against your opinion any time.  Please
don't be condescending from a high perch.

In particular, for any example of a "how a community works",
a counter example can be found.  Generalizations aren't usually
appropriate.

Just FYI, if the Apache folk were to get a request like this, I'd
place $$$ that they would reject it (but it is a guess).  All
communities have oversight - just the titles and the process
differ.  Heck, in OpenSolaris, we have a majority vote (by a
small group). In Apache, if 2 members (of a small group)
say "no", its dead.

</I'm very annoyed>


2)   We have a 32-bit user land (only) because 32-bit utilities on SPARC
     weren't any faster than 64-bits (so why support both?).

In this case, the 32 bit versions have capacity limits that are
affecting Roland and he wishes to remove those limits.  This
is not at all a performance issue, but a make it work better one.

Back to my awk example, if the problem is in /usr/gnu/bin/awk,
it seems very poor form (and a source of "huh?" bugs) to not make
the equivalent change to /usr/bin/awk.

Then again, since we can't make these changes for x86, these
seems like an even worse idea - "CR 6999999: awk works on sparc,
but not on x86".

Anyway, I've asked that this become a fast-track.  Please make
it so.

- jek3

--Boundary_(ID_Bfz5LwuK0uOzvvSNEGGCrw)-- From carlsonj@phorcys.east.sun.com Fri May 30 12:43:56 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UJhunr009781 for ; Fri, 30 May 2008 12:43:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4UJhtVO024039; Fri, 30 May 2008 12:43:55 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00C035H72L00@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 13:43:55 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00AFK5H6PQ10@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 13:43:54 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m4UJhrlW013277; Fri, 30 May 2008 15:43:53 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m4UJhr8O013274; Fri, 30 May 2008 15:43:53 -0400 (EDT) Date: Fri, 30 May 2008 15:43:52 -0400 From: James Carlson Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <4840547E.70202@sun.com> To: Joseph Kowalski Cc: John Plocher , PSARC-ext@sun.com, John Plocher Message-id: <18496.22776.761494.805076@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> Status: RO Content-Length: 1206 Joseph Kowalski writes: > John Plocher wrote: > > Joseph Kowalski wrote: > >> Sorry, I want a fast-track. > > > > What are the architectural (as opposed to C-Team, Design or RE) issues? > >> > >> 1) I believe this is an incomplete project. > > > > This sounds to me like "go boil the ocean" scope creep. > > Sometimes the burners need to be turned on. A less dramatic (but just as effective) answer would be to work out the details of a new Big Rule: "as only 64-bit kernels are supported, all new utilities should be compiled as 64-bit objects on SPARC; existing utilities should be transitioned when practical." That leaves this project team room to avoid cranking up a stove for the existing Makefiles, but still sets the long-term direction to fix the original problem. (And, yes, there are probably exceptions for open source code that doesn't work right when compiled LP64, trivial utilities that won't see a difference, and places where 64-bit libraries are lacking.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Alan.Coopersmith@sun.com Fri May 30 12:54:08 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UJs8dl010849 for ; Fri, 30 May 2008 12:54:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4UJs7Xa026118 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 May 2008 12:54:07 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00E0J5Y55700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 12:54:05 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P0029B5Y47ZA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 12:54:04 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4UJs49a005018 for ; Fri, 30 May 2008 12:54:04 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1P00F015HQXJ00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 12:54:04 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1P0052N5Y1QY70@fe-sfbay-10.sun.com>; Fri, 30 May 2008 12:54:02 -0700 (PDT) Date: Fri, 30 May 2008 12:54:01 -0700 From: Alan Coopersmith Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <4840547E.70202@sun.com> Sender: Alan.Coopersmith@sun.com To: Joseph Kowalski Cc: John Plocher , John Plocher , PSARC-ext@sun.com Message-id: <48405B59.6050306@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 423 Joseph Kowalski wrote: > I don't see why /usr/gnu/bin/awk should get preference over /usr/bin/awk > just because its in gnucore. How about because it's already known to be 64-bit clean since the GNU utilities run on platforms that are 64-bit only, while the Solaris versions may or may not be ready to go? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From jek3@sun.com Fri May 30 13:04:20 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UK4JKu011510 for ; Fri, 30 May 2008 13:04:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m4UK46eD020164; Sat, 31 May 2008 04:04:15 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00F096F2AE00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 30 May 2008 13:04:14 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P002MF6F27WB0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 30 May 2008 13:04:14 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m4UK4DWw229260; Fri, 30 May 2008 13:04:13 -0700 (PDT) Date: Fri, 30 May 2008 10:06:26 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <18496.22776.761494.805076@gargle.gargle.HOWL> To: James Carlson Cc: John Plocher , PSARC-ext@sun.com, John Plocher Message-id: <48405E42.2090903@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> <18496.22776.761494.805076@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1217 James Carlson wrote: > Joseph Kowalski writes: > >> John Plocher wrote: >> >>> Joseph Kowalski wrote: >>> >>>> Sorry, I want a fast-track. >>>> >>> What are the architectural (as opposed to C-Team, Design or RE) issues? >>> >>>> 1) I believe this is an incomplete project. >>>> >>> This sounds to me like "go boil the ocean" scope creep. >>> >> Sometimes the burners need to be turned on. >> > > A less dramatic (but just as effective) answer would be to work out > the details of a new Big Rule: "as only 64-bit kernels are supported, > all new utilities should be compiled as 64-bit objects on SPARC; > existing utilities should be transitioned when practical." > > That leaves this project team room to avoid cranking up a stove for > the existing Makefiles, but still sets the long-term direction to fix > the original problem. (And, yes, there are probably exceptions for > open source code that doesn't work right when compiled LP64, trivial > utilities that won't see a difference, and places where 64-bit > libraries are lacking.) > Yep. I guess that wasn't clear in my ranting that this was the expected conclusion of this fast-track. +1 - jek3 From jek3@sun.com Fri May 30 13:08:25 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UK8Owt011800 for ; Fri, 30 May 2008 13:08:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m4UK8KXX021778; Sat, 31 May 2008 04:08:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P002036LVQA00@nwk-avmta-2.sfbay.sun.com>; Fri, 30 May 2008 13:08:19 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00KUM6LVV680@nwk-avmta-2.sfbay.sun.com>; Fri, 30 May 2008 13:08:19 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m4UK8Ipx229760; Fri, 30 May 2008 13:08:18 -0700 (PDT) Date: Fri, 30 May 2008 10:10:30 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48405B59.6050306@sun.com> To: Alan Coopersmith Cc: John Plocher , John Plocher , PSARC-ext@sun.com Message-id: <48405F36.4080502@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> <48405B59.6050306@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 645 Alan Coopersmith wrote: > Joseph Kowalski wrote: > >> I don't see why /usr/gnu/bin/awk should get preference over /usr/bin/awk >> just because its in gnucore. >> > > How about because it's already known to be 64-bit clean since the GNU > utilities run on platforms that are 64-bit only, while the Solaris > versions may or may not be ready to go? > Is another way to phrase this as "It was easy"? :-) To be more constructive, maybe we should look at the CLIP case. On the surface, its not relevant, but perhaps we should remember the strong advice (er, requirement) in that case of "When in Rome, do as the Romans". - jek3 From John.Plocher@sun.com Fri May 30 13:32:50 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UKWnsh013650 for ; Fri, 30 May 2008 13:32:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4UKWYGd016768 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 May 2008 21:32:48 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P0031B7QOVH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 13:32:48 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00KLC7QNV5A0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 13:32:47 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4UKWltl009382 for ; Fri, 30 May 2008 13:32:47 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1P00E017ML2H00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 13:32:47 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1P00EUC7QFMX00@fe-sfbay-09.sun.com>; Fri, 30 May 2008 13:32:39 -0700 (PDT) Date: Fri, 30 May 2008 13:32:39 -0700 From: John Plocher Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48405F36.4080502@sun.com> Sender: John.Plocher@sun.com To: Joseph Kowalski Cc: PSARC-ext@sun.com Message-id: <48406467.3070101@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> <48405B59.6050306@sun.com> <48405F36.4080502@sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 408 Joseph Kowalski wrote: > To be more constructive, maybe we should look at the CLIP > case. On the surface, its not relevant, but perhaps we should > remember the strong advice (er, requirement) in that case of > > "When in Rome, do as the Romans". Since we are moving all the inhabitants of the 'burbs into downtown Rome (/usr/bin), does that rule make sense any more? Yeah, not this case. -John From jek3@Sun.COM Fri May 30 13:35:00 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UKYxfT013729 for ; Fri, 30 May 2008 13:34:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m4UKYtbR000819; Sat, 31 May 2008 04:34:56 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P003037U7Y700@nwk-avmta-2.sfbay.sun.com>; Fri, 30 May 2008 13:34:55 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00KL07U7UXA0@nwk-avmta-2.sfbay.sun.com>; Fri, 30 May 2008 13:34:55 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m4UKYsXu232857; Fri, 30 May 2008 13:34:55 -0700 (PDT) Date: Fri, 30 May 2008 10:36:59 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48406467.3070101@Sun.Com> To: John Plocher Cc: PSARC-ext@Sun.COM Message-id: <4840656B.3050705@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> <48405B59.6050306@sun.com> <48405F36.4080502@sun.com> <48406467.3070101@Sun.Com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 499 John Plocher wrote: > Joseph Kowalski wrote: >> To be more constructive, maybe we should look at the CLIP >> case. On the surface, its not relevant, but perhaps we should >> remember the strong advice (er, requirement) in that case of >> >> "When in Rome, do as the Romans". > > Since we are moving all the inhabitants of the 'burbs into > downtown Rome (/usr/bin), does that rule make sense any more? > > Yeah, not this case. > > -John > Please, just make this case a fast-track. - jek3 From carlsonj@phorcys.east.sun.com Fri May 30 13:57:05 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UKv4uU014543 for ; Fri, 30 May 2008 13:57:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4UKuuIS025967; Fri, 30 May 2008 21:57:01 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00H0D8UZQG00@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 14:56:59 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00AS98UYPOA0@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 14:56:58 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m4UKuvAR013541; Fri, 30 May 2008 16:56:57 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m4UKuvrD013538; Fri, 30 May 2008 16:56:57 -0400 (EDT) Date: Fri, 30 May 2008 16:56:57 -0400 From: James Carlson Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48406467.3070101@Sun.Com> To: John Plocher Cc: Joseph Kowalski , PSARC-ext@sun.com Message-id: <18496.27161.898523.938866@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> <48405B59.6050306@sun.com> <48405F36.4080502@sun.com> <48406467.3070101@Sun.Com> Status: RO Content-Length: 1284 John Plocher writes: > Joseph Kowalski wrote: > > To be more constructive, maybe we should look at the CLIP > > case. On the surface, its not relevant, but perhaps we should > > remember the strong advice (er, requirement) in that case of > > > > "When in Rome, do as the Romans". > > Since we are moving all the inhabitants of the 'burbs into > downtown Rome (/usr/bin), does that rule make sense any more? Sure. Rome was never defined in terms of a directory. The "when in Rome" rule refers to groups of commands that share either a common purpose, a common set of abstractions, or a common usage model. The exact path to find the commands has little or nothing to do with it, and the paths for two different groups needn't be distinct. Thus, I'd expect "zpool" and "zfs" to be similar to each other, because they're part of an identifiable grouping. I wouldn't expect either of them to share much in common with "ifconfig" or "lumake" just because they're in the same directory. So, yes, the rule still holds, and for exactly the same reasons. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From roland.mainz@nrubsig.org Fri May 30 14:02:26 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UL2PNp014999 for ; Fri, 30 May 2008 14:02:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4UL2JlH027812; Fri, 30 May 2008 22:02:24 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00I1193W5M00@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 15:02:20 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00AJ293VPQC0@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 15:02:20 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4UKwjAN000170; Fri, 30 May 2008 21:02:19 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-145626; Fri, 30 May 2008 21:02:19 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-14206623; Fri, 30 May 2008 21:02:19 +0000 (Z) Received: from mail-in-10.arcor-online.net ([151.189.21.50] [151.189.21.50]) by relay1ib.sun.com with ESMTP id BT-MMP-1608425; Fri, 30 May 2008 21:02:18 +0000 (Z) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mail-in-10.arcor-online.net (Postfix) with ESMTP id 25EAC1F510A; Fri, 30 May 2008 23:02:17 +0200 (CEST) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id 267FA6BD83; Fri, 30 May 2008 23:02:17 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-250-045.pools.arcor-ip.net [84.58.250.45]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id A5B141DB622; Fri, 30 May 2008 23:02:16 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m4UL2CYC000672; Fri, 30 May 2008 23:02:13 +0200 (CEST) Date: Fri, 30 May 2008 23:02:12 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: Joseph Kowalski Cc: John Plocher , PSARC-ext@sun.com Message-id: <48406B54.BC233B6@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/7298/Fri May 30 21:28:07 2008 on mail-in-05.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.108sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> Status: RO Content-Length: 4453 Joseph Kowalski wrote: > John Plocher wrote: > > Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI > > This information is Copyright 2008 Sun Microsystems > > 1. Introduction > > 1.1. Project/Component Working Name: > > Switch SPARC GNU coreutils+bash from 32 to 64bit > > 1.2. Name of Document Author/Supplier: > > Author: Roland Mainz > > 1.3 Date of This Document: > > 30 May, 2008 > > 4. Technical Description > > > > gisburn: Does it require an ARC case if we switch the GNU coreutils > > from 32bit to 64bit on SPARC only (no changes in interfaces and > > delivered files)? > > plocher: It doesn't sound like this has any architectural implications... > > gisburn: Not that I am aware of. > > plocher: so, I'd say that this was the entire arc review :-) > > > > 6. Resources and Schedule > > 6.4. Steering Committee requested information > > 6.4.1. Consolidation C-team Name: > > SFW > > 6.5. ARC review type: Automatic > > 6.6. ARC Exposure: open > > Sorry, I want a fast-track. Could you please write a two-page justification with minimum 2000 words, please ? Actually I hoped to get this done this weekend - which will be likely the only free time to get it done in the next couple of weeks. If it can't be done this way then the likely only course of action is to withdraw the case since noone can work on it (because there is no time and the nerves of the person who actually wanted to work on it are completely ruined and likely noone will assign official engineering time to such an "unimportant" project (which is together with the build flag cleanup and the fixing of the dbx -check access bugs in coreutils mainly "janitor" work)). BTW: A while ago there was the question: Why is Sun so slow with adopting changes for packages or adding new stuff to SFW ? Maybe one part of the answer is: Because even small things are discussed to death, hell and beyond (just an experience of the other ARC case where I had to write 229 emails, two hours of IRC discussion and two phone calls, effectively ruining two working days). For Linux they just look at the change, document it and DO IT (and that's the reason we're using "auto-approved+automatic" for this ARC case). > 1) I believe this is an incomplete project. What's good for GNU coreutils > is also good for the rest of the utilities. The source of the > utilities doesn't > matter. > > Project completeness is always an arc concern. Why do you want that I want to do _all_ utilities in one piece ? It's technically impossible to do so for a volunteer, even for me. I can handle the utilities (including testing, code review, RTI etc.) step-by-step but certainly not all in one step. > 2) We have a 32-bit user land (only) because 32-bit utilities on SPARC > weren't any faster than 64-bits (so why support both?). Since we have > unsupported any 32-bit SPARC hardware, the change could be made > now. However, validation needs to be done that this doesn't result in > performance regression. (Should be faster on an x86 - its all about > the number of registers, not the data path.) This is a C-team (PAC?) > issue, but it should be considered. We had that discussion already. The issue is: Most of the tools in GNU coreutils are so small that the statistical noise generated by the |fork()|+|exec()|-overhead is bigger than any regressions in performance. From ksh93 we already know that the difference is barely measureable on an Ultra1/143MHZ machine running Solaris 8... and somehow I doubt it changed a lot for Solaris 11. And IMO the benefits of having updated build flags (e.g. C99/XPG6 conformance), having no 256FD limit, a larger ARG_MAX and other increased limits greatly outwheights any concerns about statistical noise in the performance data (I've tested so far "bash" and it's not worse than ksh93). However I don't have time to test each indivisual tool for performance data - I can do the test suite tests and manual testing required for putback - but doing anything beyond requires to make this a fully-blown internal project (for which there aren't engineering resources). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From roland.mainz@nrubsig.org Fri May 30 14:13:22 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4ULDLGh015457 for ; Fri, 30 May 2008 14:13:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4ULDFEO001874; Fri, 30 May 2008 22:13:18 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00I0F9M3Y000@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 15:13:15 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00AQ79M2PND0@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 15:13:14 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4UL9nDO000346; Fri, 30 May 2008 21:13:14 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-145954; Fri, 30 May 2008 21:13:14 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-9902; Fri, 30 May 2008 21:13:13 +0000 (Z) Received: from mail-in-05.arcor-online.net ([151.189.21.45] [151.189.21.45]) by relay1i.sun.com with ESMTP id BT-MMP-1722379; Fri, 30 May 2008 21:13:13 +0000 (Z) Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 7F96E1838BB; Fri, 30 May 2008 23:13:12 +0200 (CEST) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id 6DE341B8E00; Fri, 30 May 2008 23:13:12 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-250-045.pools.arcor-ip.net [84.58.250.45]) by mail-in-16.arcor-online.net (Postfix) with ESMTP id 1E029236E48; Fri, 30 May 2008 23:13:11 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m4ULD9aB000677; Fri, 30 May 2008 23:13:10 +0200 (CEST) Date: Fri, 30 May 2008 23:13:09 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: Joseph Kowalski Cc: John Plocher , PSARC-ext@sun.com, John Plocher Message-id: <48406DE5.B9BBB723@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/7297/Fri May 30 18:41:12 2008 on mail-in-16.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.083sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> Status: RO Content-Length: 2595 > Joseph Kowalski wrote: > John Plocher wrote: > > Joseph Kowalski wrote: > >> Sorry, I want a fast-track. > > > > What are the architectural (as opposed to C-Team, Design or RE) > > issues? > > > >> 1) I believe this is an incomplete project. > > > > This sounds to me like "go boil the ocean" scope creep. > > Sometimes the burners need to be turned on. > > > Roland has identified several utilities that would benefit from > > being 64 bit on 64 bit OSs, and is willing to do the work to > > "convert" them. > > OK. > > Then he (you) should do a "self review" for those specific items. > > I don't see why /usr/gnu/bin/awk should get preference over > /usr/bin/awk > just because its in gnucore. Because the OS/Net codebase is in a _much_ worse shape than GNU coreutils and "bash". GNU coreutils and "bash" are 64bit clean while the OS/Net utilities are not. This is the reason why a well-known Solaris port is _FORCED_ to implement artificial 32bit support on 64bit-only hardware. This can be cleaned-up, too - but only as an official project with full-time engineers (e.g. it's far beyond a simple weekend work). I'm technically willing todo it if someone can convince manangment that this is the right way to go and resources should be invested to make OS/Net 64bit clean. [snip] > >> 2) We have a 32-bit user land (only) because 32-bit utilities on > >> SPARC > >> weren't any faster than 64-bits (so why support both?). > > > > In this case, the 32 bit versions have capacity limits that are > > affecting Roland and he wishes to remove those limits. This > > is not at all a performance issue, but a make it work better one. > > Back to my awk example, if the problem is in /usr/gnu/bin/awk, > it seems very poor form (and a source of "huh?" bugs) to not make > the equivalent change to /usr/bin/awk. As said I am willing to do it, assuming I am assigned to do that work (estimated time for the basic tools in usr/src/cmd/ is one man-year (one engineer working a year on making it 64bit clean+testing)). I really need to get money for food, wife, baby etc. and it doesn't happen for doing non-official work the whole time. > Then again, since we can't make these changes for x86, these > seems like an even worse idea - "CR 6999999: awk works on sparc, > but not on x86". > > Anyway, I've asked that this become a fast-track. Please make > it so. I don't see a reason for this. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From roland.mainz@nrubsig.org Fri May 30 14:15:30 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4ULFTlH015662 for ; Fri, 30 May 2008 14:15:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4ULFJf9002637; Fri, 30 May 2008 22:15:25 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00J0B9PN5W00@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 15:15:23 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00A6D9PMPOD0@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 15:15:23 -0600 (MDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4ULDohM003044; Fri, 30 May 2008 21:15:22 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-146105; Fri, 30 May 2008 21:15:22 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-12506; Fri, 30 May 2008 21:15:21 +0000 (Z) Received: from mail-in-09.arcor-online.net ([151.189.21.49] [151.189.21.49]) by relay1i.sun.com with ESMTP id BT-MMP-1734294; Fri, 30 May 2008 21:15:21 +0000 (Z) Received: from mail-in-14-z2.arcor-online.net (mail-in-14-z2.arcor-online.net [151.189.8.31]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id AB253302870; Fri, 30 May 2008 23:15:20 +0200 (CEST) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-14-z2.arcor-online.net (Postfix) with ESMTP id 982EA100F9; Fri, 30 May 2008 23:15:20 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-250-045.pools.arcor-ip.net [84.58.250.45]) by mail-in-16.arcor-online.net (Postfix) with ESMTP id 129C2236E4A; Fri, 30 May 2008 23:15:20 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m4ULFHGC000680; Fri, 30 May 2008 23:15:18 +0200 (CEST) Date: Fri, 30 May 2008 23:15:17 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: James Carlson Cc: Joseph Kowalski , John Plocher , John Plocher , PSARC-ext@sun.com Message-id: <48406E65.F036DC9E@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/7297/Fri May 30 18:41:12 2008 on mail-in-16.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.064sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> <18496.22776.761494.805076@gargle.gargle.HOWL> Status: RO Content-Length: 1077 James Carlson wrote: > Joseph Kowalski writes: > > John Plocher wrote: > > > Joseph Kowalski wrote: > > >> Sorry, I want a fast-track. > > > > > > What are the architectural (as opposed to C-Team, Design or RE) issues? > > >> > > >> 1) I believe this is an incomplete project. > > > > > > This sounds to me like "go boil the ocean" scope creep. > > > > Sometimes the burners need to be turned on. > > A less dramatic (but just as effective) answer would be to work out > the details of a new Big Rule: "as only 64-bit kernels are supported, > all new utilities should be compiled as 64-bit objects on SPARC; > existing utilities should be transitioned when practical." Technicially this was the original long-term goal for SPARC and the well-known Solaris port to stuff in a build flag in usr/src/Makefile.sfw which says "kernel is always 64bit so build tools with this flag 64bit only". ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From roland.mainz@nrubsig.org Fri May 30 14:17:22 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4ULHMG8015678 for ; Fri, 30 May 2008 14:17:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4ULHK8I016164; Fri, 30 May 2008 15:17:20 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P000099SU7A00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 30 May 2008 14:17:18 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00IXQ9STLP80@nwk-avmta-1.sfbay.Sun.COM>; Fri, 30 May 2008 14:17:17 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4ULGaKL002678; Fri, 30 May 2008 21:17:17 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-146105; Fri, 30 May 2008 21:17:17 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-14226213; Fri, 30 May 2008 21:17:16 +0000 (Z) Received: from mail-in-05.arcor-online.net ([151.189.21.45] [151.189.21.45]) by relay1i.sun.com with ESMTP id BT-MMP-1728024; Fri, 30 May 2008 21:17:16 +0000 (Z) Received: from mail-in-15-z2.arcor-online.net (mail-in-15-z2.arcor-online.net [151.189.8.32]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 0DB5218356D; Fri, 30 May 2008 23:17:16 +0200 (CEST) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-15-z2.arcor-online.net (Postfix) with ESMTP id EF22E724049; Fri, 30 May 2008 23:17:15 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-058-250-045.pools.arcor-ip.net [84.58.250.45]) by mail-in-16.arcor-online.net (Postfix) with ESMTP id CB4CE236E48; Fri, 30 May 2008 23:17:15 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m4ULHDBr000684; Fri, 30 May 2008 23:17:14 +0200 (CEST) Date: Fri, 30 May 2008 23:17:13 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: Alan Coopersmith Cc: Joseph Kowalski , John Plocher , PSARC-ext@sun.com, John Plocher Message-id: <48406ED9.A51DDDA@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/7297/Fri May 30 18:41:12 2008 on mail-in-16.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.054sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> <48405B59.6050306@sun.com> Status: RO Content-Length: 829 Alan Coopersmith wrote: > Joseph Kowalski wrote: > > I don't see why /usr/gnu/bin/awk should get preference over /usr/bin/awk > > just because its in gnucore. > > How about because it's already known to be 64-bit clean since the GNU > utilities run on platforms that are 64-bit only, while the Solaris > versions may or may not be ready to go? OS/Net utilities are definately not 64bit clean (nor are the OS/Net build tools) which forces Solaris ports to always implement 32bit support (whether they want it or not). And the issue is known since at least when the 64bit support was developed for Solaris 7 and nothing was done yet to fix it. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From jek3@Sun.COM Fri May 30 14:17:48 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4ULHlwx015692 for ; Fri, 30 May 2008 14:17:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4ULHPDh003169 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 May 2008 22:17:47 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P000019TK7Z00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 14:17:44 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00I0I9TJLP90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 14:17:43 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m4ULHglb239605; Fri, 30 May 2008 14:17:42 -0700 (PDT) Date: Fri, 30 May 2008 11:19:55 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <48406B54.BC233B6@nrubsig.org> To: Roland Mainz Cc: John Plocher , PSARC-ext@Sun.COM Message-id: <48406F7B.8020807@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48406B54.BC233B6@nrubsig.org> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1803 Mostly deleted. Most of Roland's concern is his scheduling. Sorry, I don't care. Desiring to work on something this weekend, is not one of the reasons for using "self-review". Other observations follow: Roland Mainz wrote: > Why do you want that I want to do _all_ utilities in one piece ? It's > technically impossible to do so for a volunteer, even for me. I can > handle the utilities (including testing, code review, RTI etc.) > step-by-step but certainly not all in one step. > As other posts have suggested, we need to decide what the appropriate group of utilities to do as subprojects is appropriate. My "Rome" is all versions of the same basic utilities: */bin/*awk, */bin/*grep,... (well, maybe an exception for oawk). But that's just my expectation. What we need it consensus about what the neighborhoods are. (Please respect John's best practice for e-mail - read the thread to (nearly) complete before responding. Yea, I forget to do that myself all too often) >> 2) We have a 32-bit user land (only) because 32-bit utilities on SPARC >> weren't any faster than 64-bits (so why support both?). Since we have >> unsupported any 32-bit SPARC hardware, the change could be made >> now. However, validation needs to be done that this doesn't result in >> performance regression. (Should be faster on an x86 - its all about >> the number of registers, not the data path.) This is a C-team (PAC?) >> issue, but it should be considered. >> > > We had that discussion already. I assume "we" refers to some OpenSolaris discussion. Trust me, I'm not interested in all of the forums. In any case, I only included (2) for the information of the C-team. There is no architectural concern. I thought that was rather clear. - jek3 From John.Plocher@sun.com Fri May 30 15:05:13 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UM5DQO018402 for ; Fri, 30 May 2008 15:05:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4UM59th022818 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 May 2008 15:05:12 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00N0XC0M3J00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 16:05:10 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00KPUC0L7O10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 16:05:09 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4UM59Ob021269 for ; Fri, 30 May 2008 15:05:09 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1P00I01BPJL200@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 15:05:09 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1P009GSC0KD960@fe-sfbay-09.sun.com>; Fri, 30 May 2008 15:05:08 -0700 (PDT) Date: Fri, 30 May 2008 15:05:08 -0700 From: John Plocher Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <48406F7B.8020807@sun.com> Sender: John.Plocher@sun.com To: Joseph Kowalski Cc: Roland Mainz , PSARC-ext@sun.com, John Plocher Message-id: <48407A14.2050700@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48406B54.BC233B6@nrubsig.org> <48406F7B.8020807@sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 860 Joseph Kowalski wrote: > As other posts have suggested, we need to decide what the appropriate group > of utilities to do as subprojects is appropriate. I disagree that "we == PSARC" for that case. Give guidance, yes, but it is not PSARC's job to make the final decision. > My "Rome" is all versions of the same basic utilities: */bin/*awk, > */bin/*grep,... (well, > maybe an exception for oawk). You have already asserted (in the CLIP case) that the GNU utilities are in a different CLIP 'burb than the Sun/POSIX ones - you can't use CLIP to justify both positions. Either they are the same "Rome", in which case they need to follow the same CLI design pattern, or they aren't, in which case they don't need to be treated the same 64-bit way. It's a fasttrack. Times out next Friday. I won't be able to make next week's Wed PSARC meeting. -John From jek3@sun.com Fri May 30 15:30:52 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UMUpMF019762 for ; Fri, 30 May 2008 15:30:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4UMUnNs028923; Fri, 30 May 2008 23:30:49 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00101D7DZ500@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 16:30:49 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00KXLD7C7D20@brm-avmta-1.central.sun.com>; Fri, 30 May 2008 16:30:48 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m4UMUlXc251219; Fri, 30 May 2008 15:30:47 -0700 (PDT) Date: Fri, 30 May 2008 12:32:59 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <48407A14.2050700@Sun.Com> To: John Plocher Cc: Roland Mainz , PSARC-ext@sun.com, John Plocher Message-id: <4840809B.5080803@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48406B54.BC233B6@nrubsig.org> <48406F7B.8020807@sun.com> <48407A14.2050700@Sun.Com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1297 John Plocher wrote: > Joseph Kowalski wrote: >> As other posts have suggested, we need to decide what the appropriate >> group >> of utilities to do as subprojects is appropriate. > > I disagree that "we == PSARC" for that case. Give guidance, yes, but > it is not PSARC's job to make the final decision. Agreed. (I guess that parses as I'm agreeing with your disagreement with me. Does that make me "disagreeable"? Uh, don't answer that.) However, I'll also point out this isn't a community decision either. It is a distro decision. >> My "Rome" is all versions of the same basic utilities: */bin/*awk, >> */bin/*grep,... (well, >> maybe an exception for oawk). > > You have already asserted (in the CLIP case) that the GNU utilities are > in a different CLIP 'burb than the Sun/POSIX ones - you can't use CLIP to > justify both positions. > > Either they are the same "Rome", in which case they need to follow > the same CLI design pattern, or they aren't, in which case they > don't need to be treated the same 64-bit way. You are taking this *way* to literal. The point is that there needs to be partitioning. The axis of partitioning is open for discussion. > It's a fasttrack. Times out next Friday. I won't be able to make next > week's Wed PSARC meeting. Thanks. - jek3 From Mark.Carlson@sun.com Fri May 30 16:46:09 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UNk8wK024970 for ; Fri, 30 May 2008 16:46:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m4UNjuoM006705 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 31 May 2008 07:46:08 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P00C09GOVQG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 16:46:07 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P008WDGOU4AA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 16:46:06 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4UNk6ah021984 for ; Fri, 30 May 2008 23:46:06 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1P00E01GN2U100@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 May 2008 17:46:06 -0600 (MDT) Received: from Macintosh-205.local ([71.237.94.98]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1P00K2GGOT0I60@mail-amer.sun.com>; Fri, 30 May 2008 17:46:05 -0600 (MDT) Date: Fri, 30 May 2008 17:46:03 -0600 From: "Mark A. Carlson" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <4840809B.5080803@sun.com> Sender: Mark.Carlson@sun.com To: Joseph Kowalski Cc: John Plocher , PSARC-ext@sun.com Message-id: <484091BB.8090306@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HmcapMwTv11Cmo9GXMbUfw)" X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48406B54.BC233B6@nrubsig.org> <48406F7B.8020807@sun.com> <48407A14.2050700@Sun.Com> <4840809B.5080803@sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 4485 This is a multi-part message in MIME format. --Boundary_(ID_HmcapMwTv11Cmo9GXMbUfw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Guys, I thought we agreed that when the discussion thread gets this long, we take it off the list and set some time aside at a meeting. -- mark Joseph Kowalski wrote: > John Plocher wrote: > >> Joseph Kowalski wrote: >> >>> As other posts have suggested, we need to decide what the appropriate >>> group >>> of utilities to do as subprojects is appropriate. >>> >> I disagree that "we == PSARC" for that case. Give guidance, yes, but >> it is not PSARC's job to make the final decision. >> > > Agreed. (I guess that parses as I'm agreeing with your disagreement > with me. Does that make me "disagreeable"? Uh, don't answer that.) > > However, I'll also point out this isn't a community decision either. > > It is a distro decision. > > >>> My "Rome" is all versions of the same basic utilities: */bin/*awk, >>> */bin/*grep,... (well, >>> maybe an exception for oawk). >>> >> You have already asserted (in the CLIP case) that the GNU utilities are >> in a different CLIP 'burb than the Sun/POSIX ones - you can't use CLIP to >> justify both positions. >> >> Either they are the same "Rome", in which case they need to follow >> the same CLI design pattern, or they aren't, in which case they >> don't need to be treated the same 64-bit way. >> > > You are taking this *way* to literal. The point is that there needs to > be partitioning. The axis of partitioning is open for discussion. > > >> It's a fasttrack. Times out next Friday. I won't be able to make next >> week's Wed PSARC meeting. >> > > Thanks. > > - jek3 > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > --Boundary_(ID_HmcapMwTv11Cmo9GXMbUfw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Guys, I thought we agreed that when the discussion thread gets this
long, we take it off the list and set some time aside at a meeting.

-- mark

Joseph Kowalski wrote: 
John Plocher wrote:
  
Joseph Kowalski wrote:
    
As other posts have suggested, we need to decide what the appropriate 
group
of utilities to do as subprojects is appropriate.
      
I disagree that "we == PSARC" for that case.  Give guidance, yes, but
it is not PSARC's job to make the final decision.
    

Agreed.  (I guess that parses as I'm agreeing with your disagreement
with me.  Does that make me "disagreeable"?  Uh, don't answer that.)

However, I'll also point out this isn't a community decision either.

It is a distro decision.

  
My "Rome" is all versions of the same basic utilities: */bin/*awk, 
*/bin/*grep,... (well,
maybe an exception for oawk).
      
You have already asserted (in the CLIP case) that the GNU utilities are
in a different CLIP 'burb than the Sun/POSIX ones - you can't use CLIP to
justify both positions.

Either they are the same "Rome", in which case they need to follow
the same CLI design pattern, or they aren't, in which case they
don't need to be treated the same 64-bit way.
    

You are taking this *way* to literal.  The point is that there needs to
be partitioning.  The axis of partitioning is open for discussion.

  
It's a fasttrack.  Times out next Friday.  I won't be able to make next
week's Wed PSARC meeting.
    

Thanks.

- jek3

_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
--Boundary_(ID_HmcapMwTv11Cmo9GXMbUfw)-- From Darren.Moffat@sun.com Mon Jun 2 02:56:51 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m529uo81002026 for ; Mon, 2 Jun 2008 02:56:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m529umbN024752 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Jun 2008 17:56:49 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1T00303YAORU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 02:56:48 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1T00KUAYAN4F70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 02:56:48 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m529ukax004153 for ; Mon, 02 Jun 2008 09:56:46 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1T00401WN7N000@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 10:56:46 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1T00M48YA975D0@fe-emea-09.sun.com>; Mon, 02 Jun 2008 10:56:34 +0100 (BST) Date: Mon, 02 Jun 2008 10:56:33 +0100 From: Darren J Moffat Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48404431.9010701@sun.com> Sender: Darren.Moffat@sun.com To: Joseph Kowalski Cc: John Plocher , PSARC-ext@sun.com Message-id: <4843C3D1.8060203@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 2401 Joseph Kowalski wrote: > John Plocher wrote: >> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Switch SPARC GNU coreutils+bash from 32 to 64bit >> 1.2. Name of Document Author/Supplier: >> Author: Roland Mainz >> 1.3 Date of This Document: >> 30 May, 2008 >> 4. Technical Description >> >> gisburn: Does it require an ARC case if we switch the GNU coreutils >> from 32bit to 64bit on SPARC only (no changes in interfaces and >> delivered files)? >> plocher: It doesn't sound like this has any architectural >> implications... >> gisburn: Not that I am aware of. >> plocher: so, I'd say that this was the entire arc review :-) >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> SFW >> 6.5. ARC review type: Automatic >> 6.6. ARC Exposure: open >> > > Sorry, I want a fast-track. > > 1) I believe this is an incomplete project. What's good for GNU > coreutils > is also good for the rest of the utilities. The source of the > utilities doesn't > matter. > > Project completeness is always an arc concern. > > 2) We have a 32-bit user land (only) because 32-bit utilities on SPARC > weren't any faster than 64-bits (so why support both?). Since we have > unsupported any 32-bit SPARC hardware, the change could be made > now. However, validation needs to be done that this doesn't result in > performance regression. (Should be faster on an x86 - its all about > the number of registers, not the data path.) This is a C-team (PAC?) > issue, but it should be considered. I completely agree with Joe here. I'm derailing this automatic approval. I want at least a fast-track that explains why the asymetry between SPARC and x86 is actually useful in addition to what Joe asked for. I think this should actually be a full case rather than a fast-track given this would be a significant architectural change. As Joe said the GNU part is irrelevant here what is relevant is the change in direction. This case, if approved, will need an opinion to document the new policy and will also likely need updates to various best practices. -- Darren J Moffat From sacadmin Mon Jun 2 07:54:31 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52EsUXN008624 for ; Mon, 2 Jun 2008 07:54:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m52EsGNI012011 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Mon, 2 Jun 2008 22:54:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00E03C2SY700@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Mon, 02 Jun 2008 07:54:28 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00EORC2S7Q00@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Mon, 02 Jun 2008 07:54:28 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52EsS3L023275 for ; Mon, 02 Jun 2008 14:54:28 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1U00A01AZTF800@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for psarc-members@sun.com (ORCPT psarc-members@sun.com); Mon, 02 Jun 2008 08:54:28 -0600 (MDT) Received: from Macintosh-205.local ([71.237.94.98]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1U00HHEC2JFY50@mail-amer.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Mon, 02 Jun 2008 08:54:20 -0600 (MDT) Date: Mon, 02 Jun 2008 08:54:19 -0600 From: "Mark A. Carlson" Subject: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review]] Sender: Mark.Carlson@sun.com To: Rick Matthews , Aarti Pai Cc: psarc-members@sun.com Message-id: <4844099B.3000400@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_9/uZTkhQCxKZpsR7C0zhNA)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 10867 This is a multi-part message in MIME format. --Boundary_(ID_9/uZTkhQCxKZpsR7C0zhNA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Rick, Can we schedule some time at open ARC business to discuss this? Perhaps as a filler item between cases. I know we have a pretty full agenda already. -- mark --Boundary_(ID_9/uZTkhQCxKZpsR7C0zhNA) Content-type: message/rfc822; name="Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 SelfReview].eml" Return-path: Received: from fe-amer-10.sun.com ([192.18.109.80]) by amer5-mail1.central.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K1T00IBUYDWBTB0@amer5-mail1.central.sun.com> for markcarl@amer5-mail1.Central.Sun.COM; Mon, 02 Jun 2008 03:58:44 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1T00G01Y7WAL00@mail-amer.sun.com> for markcarl@amer5-mail1.Central.Sun.COM (ORCPT mark.carlson@sun.com); Mon, 02 Jun 2008 03:58:44 -0600 (MDT) Received: from phys-amer5-1.central.sun.com ([129.147.157.54]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K1T00AYSYDWN520@mail-amer.sun.com> for markcarl@amer5-mail1.Central.Sun.COM (ORCPT mark.carlson@sun.com); Mon, 02 Jun 2008 03:58:44 -0600 (MDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by amer5-mail1.central.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K1T00IBSYDWBTB0@amer5-mail1.central.sun.com> for markcarl@amer5-mail1.Central.Sun.COM (ORCPT mark.carlson@sun.com); Mon, 02 Jun 2008 03:58:44 -0600 (MDT) Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m529who0023281; Mon, 02 Jun 2008 03:58:43 -0600 (MDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m529wgJU023588; Mon, 02 Jun 2008 02:58:43 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1T00009YDTXD00@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 03:58:41 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1T00FFDYDTRI80@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 03:58:41 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m529wfBl008176; Mon, 02 Jun 2008 09:58:41 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-205737; Mon, 02 Jun 2008 09:58:41 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-18464463; Mon, 02 Jun 2008 09:58:39 +0000 (Z) Received: from mail.opensolaris.org ([72.5.123.71] [72.5.123.71]) by relay1ib.sun.com with ESMTP id BT-MMP-2898882; Mon, 02 Jun 2008 09:58:39 +0000 (Z) Received: by mail.opensolaris.org (Postfix, from userid 501) id 04A4F18A517; Mon, 02 Jun 2008 02:58:39 -0700 (PDT) Received: from oss-mail1.opensolaris.org (localhost [127.0.0.1]) by mail.opensolaris.org (Postfix) with ESMTP id 55A3618A4DD; Mon, 02 Jun 2008 02:58:29 -0700 (PDT) Received: by mail.opensolaris.org (Postfix, from userid 501) id D5D8218A4D3; Mon, 02 Jun 2008 02:58:27 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mail.opensolaris.org (Postfix) with ESMTP id 4BEC518A4CC for ; Mon, 02 Jun 2008 02:57:42 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m529vgAm007970 for ; Mon, 02 Jun 2008 09:57:42 +0000 (GMT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m529vg38045777; Mon, 02 Jun 2008 02:57:42 -0700 (PDT) Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m529uo81002026 for ; Mon, 02 Jun 2008 02:56:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL, v2.2) with ESMTP id m529umbN024752 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 02 Jun 2008 17:56:49 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1T00303YAORU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 02:56:48 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1T00KUAYAN4F70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 02:56:48 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m529ukax004153 for ; Mon, 02 Jun 2008 09:56:46 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1T00401WN7N000@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 10:56:46 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1T00M48YA975D0@fe-emea-09.sun.com>; Mon, 02 Jun 2008 10:56:34 +0100 (BST) Date: Mon, 02 Jun 2008 10:56:33 +0100 From: Darren J Moffat Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48404431.9010701@sun.com> Sender: opensolaris-arc-bounces@opensolaris.org To: Joseph Kowalski Cc: PSARC-ext@sun.com, John Plocher Errors-to: opensolaris-arc-bounces@opensolaris.org Message-id: <4843C3D1.8060203@Sun.COM> X-Envelope-from: Mark.Carlson@Sun.COM X-Envelope-to: psarc-members <@smarthost.sun.com:psarc-members@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: list X-BeenThere: opensolaris-arc@opensolaris.org Delivered-to: opensolaris-arc@opensolaris.org X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on oss-mail1.opensolaris.org X-Original-To: opensolaris-arc@opensolaris.org X-PMX-Version: 5.4.1.325704 X-Antispam: No, score=0.0/5.0, scanned in 0.088sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> X-Mailman-Version: 2.1.9 List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: List-Id: Discussion of ARC issues affecting OpenSolaris User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Original-recipient: rfc822;mark.carlson@sun.com X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,RCVD_IN_DNSWL_LOW autolearn=unavailable version=3.2.3 X-Spam-Level: Joseph Kowalski wrote: > John Plocher wrote: >> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Switch SPARC GNU coreutils+bash from 32 to 64bit >> 1.2. Name of Document Author/Supplier: >> Author: Roland Mainz >> 1.3 Date of This Document: >> 30 May, 2008 >> 4. Technical Description >> >> gisburn: Does it require an ARC case if we switch the GNU coreutils >> from 32bit to 64bit on SPARC only (no changes in interfaces and >> delivered files)? >> plocher: It doesn't sound like this has any architectural >> implications... >> gisburn: Not that I am aware of. >> plocher: so, I'd say that this was the entire arc review :-) >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> SFW >> 6.5. ARC review type: Automatic >> 6.6. ARC Exposure: open >> > > Sorry, I want a fast-track. > > 1) I believe this is an incomplete project. What's good for GNU > coreutils > is also good for the rest of the utilities. The source of the > utilities doesn't > matter. > > Project completeness is always an arc concern. > > 2) We have a 32-bit user land (only) because 32-bit utilities on SPARC > weren't any faster than 64-bits (so why support both?). Since we have > unsupported any 32-bit SPARC hardware, the change could be made > now. However, validation needs to be done that this doesn't result in > performance regression. (Should be faster on an x86 - its all about > the number of registers, not the data path.) This is a C-team (PAC?) > issue, but it should be considered. I completely agree with Joe here. I'm derailing this automatic approval. I want at least a fast-track that explains why the asymetry between SPARC and x86 is actually useful in addition to what Joe asked for. I think this should actually be a full case rather than a fast-track given this would be a significant architectural change. As Joe said the GNU part is irrelevant here what is relevant is the change in direction. This case, if approved, will need an opinion to document the new policy and will also likely need updates to various best practices. -- Darren J Moffat _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org --Boundary_(ID_9/uZTkhQCxKZpsR7C0zhNA)-- From Alan.Coopersmith@sun.com Mon Jun 2 08:12:36 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52FCZFa009364 for ; Mon, 2 Jun 2008 08:12:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52FCWiv018125 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Jun 2008 16:12:34 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00007CWWZQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 09:12:32 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00LZ6CWVLA20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 09:12:31 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m52FCVt9002875 for ; Mon, 02 Jun 2008 08:12:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1U00701CT10X00@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 08:12:31 -0700 (PDT) Received: from [10.6.102.118] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1U00DDXCWUQ460@fe-sfbay-09.sun.com>; Mon, 02 Jun 2008 08:12:31 -0700 (PDT) Date: Mon, 02 Jun 2008 08:12:30 -0700 From: Alan Coopersmith Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <4840547E.70202@sun.com> Sender: Alan.Coopersmith@sun.com To: Joseph Kowalski Cc: John Plocher , John Plocher , PSARC-ext@sun.com Message-id: <48440DDE.2050403@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 944 Joseph Kowalski wrote: > Speaking of how a "volunteer open *source* community works", > this is a proposal about how a *binary* distribution should be constructed. > This is Sun's decision or a decision about a future OpenSolaris > reference distribution. Tell me again how a volunteer makes this > distribution configuration decision. By participating in the OpenSolaris project, which now includes the building of the OpenSolaris binary distributions. The OpenSolaris world has changed from the days when distros were all someone else's problem. Should Sun wish to change this in the future Solaris.next fork off the OpenSolaris distro, they can - that choice is truly Sun's to make - but the OpenSolaris 2008.05 and successor distros are being built with the community, and thus volunteers can make changes like this. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From bart.smaalders@sun.com Mon Jun 2 10:06:44 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52H6i1Z013425 for ; Mon, 2 Jun 2008 10:06:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m52H6fA7010706; Mon, 2 Jun 2008 11:06:41 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00909I756H00@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 11:06:41 -0600 (MDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00LIDI75LDB0@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 11:06:41 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m52H6f2k015313; Mon, 02 Jun 2008 17:06:41 +0000 (GMT) Date: Mon, 02 Jun 2008 10:06:40 -0700 From: Bart Smaalders Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <4843C3D1.8060203@Sun.COM> To: Darren J Moffat Cc: Joseph Kowalski , John Plocher , PSARC-ext@sun.com Message-id: <484428A0.6010108@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 1209 Darren J Moffat wrote: > I'm derailing this automatic approval. I want at least a fast-track > that explains why the asymetry between SPARC and x86 is actually useful > in addition to what Joe asked for. Because we support x86 machines that don't implement 64 bit support? The same reason we ship a 32 bit and a 64 bit x86 kernel? > I think this should actually be a > full case rather than a fast-track given this would be a significant > architectural change. As Joe said the GNU part is irrelevant here what > is relevant is the change in direction. > Whether a particular executable is delivered as a 32 bit binary, 64 bit binary or shell script/java/python.... seems more of an implementation detail rather than an architecture change. I assume that the proposal here is to deliver 64 bit versions of these commands on sparc, and both 32 and 64 bit versions on x86. My question here is whether there is a plan about what to do w/ 32bit only (x86) systems in regards to whatever limit this change avoids.... - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From gdamore@sun.com Mon Jun 2 10:32:50 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52HWoYj014413 for ; Mon, 2 Jun 2008 10:32:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m52HWook024330 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Jun 2008 10:32:50 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00L0RJEQHX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 10:32:50 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00K3PJEP8P20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 10:32:49 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m52HWnHi021068 for ; Mon, 02 Jun 2008 10:32:49 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1U00801I00FF00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 10:32:49 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1U000YQJEKUU40@fe-sfbay-09.sun.com>; Mon, 02 Jun 2008 10:32:44 -0700 (PDT) Date: Mon, 02 Jun 2008 10:32:25 -0700 From: "Garrett D'Amore" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <484428A0.6010108@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: Darren J Moffat , Joseph Kowalski , John Plocher , PSARC-ext@sun.com Message-id: <48442EA9.7020502@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2371 Bart Smaalders wrote: > Darren J Moffat wrote: > >> I'm derailing this automatic approval. I want at least a fast-track >> that explains why the asymetry between SPARC and x86 is actually >> useful in addition to what Joe asked for. > > Because we support x86 machines that don't implement 64 bit support? > The same reason we ship a 32 bit and a 64 bit x86 kernel? > >> I think this should actually be a full case rather than a fast-track >> given this would be a significant architectural change. As Joe said >> the GNU part is irrelevant here what is relevant is the change in >> direction. >> > > Whether a particular executable is delivered as a 32 bit binary, 64 > bit binary > or shell script/java/python.... seems more of an implementation detail > rather > than an architecture change. > > I assume that the proposal here is to deliver 64 bit versions of these > commands > on sparc, and both 32 and 64 bit versions on x86. > > My question here is whether there is a plan about what to do w/ 32bit > only (x86) systems in regards to whatever limit this change avoids.... I think the above question (the behavioral difference) is one that really needs to be addressed. It may be that the answer is that we don't care about the limit on 32-bit only systems, but what are we going to do for 64-bit-capable x86 boxes? I am pretty unhappy with the current isaexec() solution - the extra fork/exec combo seems "unfortunate", particularly for utilities that might be executed heavily in embedded scripts. (The shell, and coreutils, seems to fall into this category.) My personal preference, for now, would be to deliver *both* 32- and 64-bit versions of the applications for both SPARC and x86, but deliver the 64-bit versions in a separate path (/usr/bin/sparcv9 and /usr/bin/amd64 or somesuch), so that end users can just adjust their $PATH appropriately if they know they need or want 64-bit capable programs (I think for the vast majority of users, this will not be necessary.) This has the added advantage of minimizing the ARC "impact" of this, by not changing the "default" version of the tools right now. (And doesn't preclude making such a change later, particularly if at some point we decide we can stop supporting 32-bit-only processors, which I imagine we might do some number of years in the future.) -- Garrett From John.Plocher@sun.com Mon Jun 2 11:17:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52IHF3P016765 for ; Mon, 2 Jun 2008 11:17:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m52IGvbW000228 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Jun 2008 02:17:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00017LGN3U00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 11:17:11 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00K4ALGL8O50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 11:17:09 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m52IH91w027667 for ; Mon, 02 Jun 2008 11:17:09 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1U00M01KUGXA00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 11:17:09 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1U00CN4LGFW290@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 11:17:03 -0700 (PDT) Date: Mon, 02 Jun 2008 11:17:02 -0700 From: John Plocher Subject: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] Sender: John.Plocher@sun.com To: PSARC-ext@sun.com Message-id: <4844391E.1070504@Sun.Com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_SfAmh7c3Tq1rxXIyR6P11g)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 11200 This is a multi-part message in MIME format. --Boundary_(ID_SfAmh7c3Tq1rxXIyR6P11g) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT [Arggh - I forgot to re-address this to PSARC-ext to make sure it ended up in the case log... -John] -------- Original Message -------- Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Date: Mon, 02 Jun 2008 11:08:33 -0700 From: John Plocher To: Richard L. Hamilton CC: opensolaris-arc@opensolaris.org References: <12790891.1212242421785.JavaMail.Twebapp@oss-app1> [I'm attaching Richard's original mail since it was only sent to opensolaris-arc and probably didn't get into the case mail log] Richard L. Hamilton wrote: > I can think of three main categories of capacity limits on 32-bit that might > be higher on 64-bit: > * file size max of 2GB > * register size and usage > * available address space, and therefore amount that can be mmap()'d at once > (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) > > AFAIK, only where the address space is an issue is 64-bit all that beneficial > on SPARC. > ... > The file size limit can be lifted on 32-bit with large file support (lfcompile(5)). > The register usage can be altered in an often helpful way by compiling with > -xarch=v8plus. Even the stdio problem could be circumvented (using AT&T > SFIO in place of libc stdio), although that may be an architectural no-no for > now. Roland: Could you respond to Richards comments - it may be that by using large file support you could get the behavior you want - on both x86 and SPARC. > IMO, a better statement might be that if something is being touched, the > compilation options including 32 vs 64-bit, and the other measures for 32-bit, > should be re-examined to increase capacity limits without performance > regression or breaking compatibility (i.e. public libs that have been available > in 32-bit should continue to be, and if not already both 32-bit and 64-bit, > usually should be) with any supported platform. This seems to be a reasonable "design/implementation policy" that could replace the defacto "do it all or do nothing" and "you can't do it anyways" ones. Garrett D'Amore wrote: > Bart Smaalders wrote: >> My question here is whether there is a plan about what to do w/ 32bit >> only (x86) systems in regards to whatever limit this change avoids.... > > I think the above question (the behavioral difference) is one that > really needs to be addressed. It may be that the answer is that we > don't care about the limit on 32-bit only systems, but what are we going > to do for 64-bit-capable x86 boxes? Build and deliver 64-bit binaries? Maybe even as a followup to this project? With a 32-bit system, you may just be stuck with 32 bit limits. Tough. With a 64-bit system, you shouldn't be stuck with a 32-bit limit just because someone might have a 32 bit system that behaves differently. Isn't that why we developed 64 bit systems in the first place? Isn't that why we are doing the OpenSolaris thing - to find and fix these kinds of problems? -John --Boundary_(ID_SfAmh7c3Tq1rxXIyR6P11g) Content-type: message/rfc822; name="Attached Message" Return-path: Received: from fe-sfbay-09.sun.com ([192.18.34.119]) by sfbay2-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K1Q00CX3K9K6P90@sfbay2-mail1.sfbay.sun.com>; Sat, 31 May 2008 07:00:56 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1Q00K01JX8FH00@fe-sfbay-09.sun.com>; Sat, 31 May 2008 07:00:56 -0700 (PDT) Received: from phys-sfbay2-1.sfbay.sun.com ([129.145.47.16]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K1Q00DZVK9KWS20@fe-sfbay-09.sun.com>; Sat, 31 May 2008 07:00:56 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by sfbay2-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K1Q00CX1K9K6P90@sfbay2-mail1.sfbay.sun.com>; Sat, 31 May 2008 07:00:56 -0700 (PDT) Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4VE0tJn045469; Sat, 31 May 2008 07:00:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4VE0lFL026186; Sat, 31 May 2008 15:00:48 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1Q00807K9BFJ00@brm-avmta-1.central.sun.com>; Sat, 31 May 2008 08:00:47 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1Q0082IK9AAQ70@brm-avmta-1.central.sun.com>; Sat, 31 May 2008 08:00:46 -0600 (MDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m4VE0j8D027655; Sat, 31 May 2008 14:00:46 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay22i.sun.com with ESMTP id BT-MMP-236272; Sat, 31 May 2008 14:00:45 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-6991783; Sat, 31 May 2008 14:00:44 +0000 (Z) Received: from mail.opensolaris.org ([72.5.123.71] [72.5.123.71]) by relay21i.sun.com with ESMTP id BT-MMP-8409118; Sat, 31 May 2008 14:00:44 +0000 (Z) Received: by mail.opensolaris.org (Postfix, from userid 501) id CE2BD17BE8F; Sat, 31 May 2008 07:00:43 -0700 (PDT) Received: from oss-mail1.opensolaris.org (localhost [127.0.0.1]) by mail.opensolaris.org (Postfix) with ESMTP id 0092717BE77; Sat, 31 May 2008 07:00:32 -0700 (PDT) Received: by mail.opensolaris.org (Postfix, from userid 501) id 1D05E17BE62; Sat, 31 May 2008 07:00:31 -0700 (PDT) Received: from oss-app1 (unknown [72.5.123.64]) by mail.opensolaris.org (Postfix) with ESMTP id BFFC417BE5B for ; Sat, 31 May 2008 07:00:21 -0700 (PDT) Date: Sat, 31 May 2008 06:59:51 -0700 (PDT) From: "Richard L. Hamilton" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 In-reply-to: <48404BE2.4060207@Sun.Com> Sender: opensolaris-arc-bounces@opensolaris.org To: opensolaris-arc@opensolaris.org Errors-to: opensolaris-arc-bounces@opensolaris.org Message-id: <12790891.1212242421785.JavaMail.Twebapp@oss-app1> X-Envelope-from: John.Plocher@Sun.COM X-Envelope-to: PSARC-ext <@smarthost.sun.com:PSARC-ext@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: list X-BeenThere: opensolaris-arc@opensolaris.org Delivered-to: opensolaris-arc@opensolaris.org X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on oss-mail1.opensolaris.org X-Original-To: opensolaris-arc@opensolaris.org X-OpenSolaris-URL: http://www.opensolaris.org/jive/message.jspa?messageID=241980&tstart=0#241980 X-Antispam: No, score=0.0/5.0, scanned in 0.096sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ X-Mailman-Version: 2.1.9 List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: List-Id: Discussion of ARC issues affecting OpenSolaris X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,RDNS_NONE autolearn=no version=3.2.3 X-Spam-Level: > In this case, the 32 bit versions have capacity > limits that are > affecting Roland and he wishes to remove those > limits. This > is not at all a performance issue, but a make it work > better one. Last I heard, unless there was some benefit to be gained, 64-bit was usually _slower_ on SPARC than 32-bit (unlike x86, where all the extra registers are a big help), due to larger address constants meaning more data to fetch (and less effective use of cache?), etc. I can think of three main categories of capacity limits on 32-bit that might be higher on 64-bit: * file size max of 2GB * register size and usage * available address space, and therefore amount that can be mmap()'d at once (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) AFAIK, only where the address space is an issue is 64-bit all that beneficial on SPARC. The file size limit can be lifted on 32-bit with large file support (lfcompile(5)). The register usage can be altered in an often helpful way by compiling with -xarch=v8plus. Even the stdio problem could be circumvented (using AT&T SFIO in place of libc stdio), although that may be an architectural no-no for now. A cursory glance at the programs in question suggests that not all of them would have any use for a larger address space; those could probably receive all the benefits (and not the possible performance drawbacks) of 64-bitness by just being built with large file support and compiled as v8plus. Where that would be sufficient to reach maximum capacity limits, I think performance testing of large file+v8plus versus v9 (64-bit) should be considered, to avoid regression. So I think a rule to transition programs to 64-bit would be a very blunt object. IMO, a better statement might be that if something is being touched, the compilation options including 32 vs 64-bit, and the other measures for 32-bit, should be re-examined to increase capacity limits without performance regression or breaking compatibility (i.e. public libs that have been available in 32-bit should continue to be, and if not already both 32-bit and 64-bit, usually should be) with any supported platform. Less important, but still desirable, would be, as time permits, to re-examine the options looking for performance _increases_, subject to the same constraints. I'm all for lifting capacity limits (which is one of the reasons I think that GNU awk is one of their more examplary programs - it doesn't choke on input records with millions of fields! and yet, they coordinated with the authors of the original to maintain reasonable compatibility), but if possible, I'd prefer not to take a performance hit to do it. This message posted from opensolaris.org _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org --Boundary_(ID_SfAmh7c3Tq1rxXIyR6P11g)-- From Alan.Coopersmith@sun.com Mon Jun 2 11:24:07 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52IO69I016911 for ; Mon, 2 Jun 2008 11:24:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52INdQS014659 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Jun 2008 19:24:05 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0000XLS3D100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 11:24:03 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00K9ILS39160@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 11:24:03 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m52IO3IU018754 for ; Mon, 02 Jun 2008 11:24:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1U00201KH6BW00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 11:24:03 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1U003U9LS24KD0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 11:24:02 -0700 (PDT) Date: Mon, 02 Jun 2008 11:24:02 -0700 From: Alan Coopersmith Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: <4844391E.1070504@Sun.Com> Sender: Alan.Coopersmith@sun.com To: "Richard L. Hamilton" Cc: PSARC-ext@sun.com Message-id: <48443AC2.7030501@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4844391E.1070504@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 760 Richard L. Hamilton wrote: >> I can think of three main categories of capacity limits on 32-bit that >> might >> be higher on 64-bit: >> * file size max of 2GB >> * register size and usage >> * available address space, and therefore amount that can be mmap()'d >> at once >> (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) Yes, the 256 FILE stdio limit is lifted in 64-bit. The other main advantage I'm aware of is 64-bit time_t, so you can work with timestamps outside the 1970-2038 range, which there is no way to do in 32-bit (the large file compilation flags only raised the sizes to 64-bit, not the timestamps). -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From bart.smaalders@sun.com Mon Jun 2 11:28:26 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52ISPXq017023 for ; Mon, 2 Jun 2008 11:28:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52ISCOE016795; Mon, 2 Jun 2008 19:28:21 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00003LZ8JQ00@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 11:28:20 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00KPILZ88Z50@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 11:28:20 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m52ISJfp017402; Mon, 02 Jun 2008 18:28:19 +0000 (GMT) Date: Mon, 02 Jun 2008 11:28:19 -0700 From: Bart Smaalders Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48442EA9.7020502@sun.com> To: "Garrett D'Amore" Cc: Darren J Moffat , Joseph Kowalski , John Plocher , PSARC-ext@sun.com Message-id: <48443BC3.1010802@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 1925 Garrett D'Amore wrote: > My personal preference, for now, would be to deliver *both* 32- and > 64-bit versions of the applications for both SPARC and x86, but deliver > the 64-bit versions in a separate path (/usr/bin/sparcv9 and > /usr/bin/amd64 or somesuch), so that end users can just adjust their > $PATH appropriately if they know they need or want 64-bit capable > programs (I think for the vast majority of users, this will not be > necessary.) > > This has the added advantage of minimizing the ARC "impact" of this, by > not changing the "default" version of the tools right now. (And doesn't > preclude making such a change later, particularly if at some point we > decide we can stop supporting 32-bit-only processors, which I imagine we > might do some number of years in the future.) Why should we continue to deliver a 32 bit version of a command, if today we always exec the 64 bit varient? Anything that goes through isaexec today should be 64 bit only on SPARC. The fact that we still use isaexec on SPARC at all is a bug. x86 will for now need to deliver both 32 and 64 bit binaries. If you're worried about the performance issues involved w/ isaexec, then let's design something better.... but have the user adjust their path is a complete non-starter and we still need isaexec for the correctness cases (proc tools, etc). As an example, to replace most instances of isaexec, we could create /usr/bin/isaexec as a mount point, and then during boot mount /usr/bin/i86 or /usr/bin/amd64 on /usr/bin/isaexec as a loopback mount. We also change the isaexec hardlinks in /usr/bin to be symbolic links pointing to /usr/bin/isaexec/{cmdname}.... no more runtime isaexec overhead and no fiddling w/ user paths. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Nicolas.Williams@sun.com Mon Jun 2 11:38:19 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52IcICa017484 for ; Mon, 2 Jun 2008 11:38:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52IcEJ1020941; Mon, 2 Jun 2008 19:38:16 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0000RMFQUZ00@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 11:38:14 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00KE3MFP8O60@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 11:38:13 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m52IcCJ3005210; Mon, 02 Jun 2008 13:38:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m52IcCMw005209; Mon, 02 Jun 2008 13:38:12 -0500 (CDT) Date: Mon, 02 Jun 2008 13:38:12 -0500 From: Nicolas Williams Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: <48443AC2.7030501@sun.com> To: Alan Coopersmith Cc: "Richard L. Hamilton" , PSARC-ext@sun.com Mail-followup-to: Alan Coopersmith , "Richard L. Hamilton" , PSARC-ext@sun.com Message-id: <20080602183811.GB2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1289 On Mon, Jun 02, 2008 at 11:24:02AM -0700, Alan Coopersmith wrote: > Richard L. Hamilton wrote: > >> I can think of three main categories of capacity limits on 32-bit that > >> might > >> be higher on 64-bit: > >> * file size max of 2GB > >> * register size and usage > >> * available address space, and therefore amount that can be mmap()'d > >> at once > >> (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) > > Yes, the 256 FILE stdio limit is lifted in 64-bit. The other main Wait a minute. Our stdio does not support more than 256 open FILEs if you use it right (it does entail raising the soft fildes limit; the utilities we're talking about may not fork()/exec() other programs that don't know how to use stdio the new way, so raising the soft fildes limit when the utility starts should be OK). > advantage I'm aware of is 64-bit time_t, so you can work with timestamps > outside the 1970-2038 range, which there is no way to do in 32-bit (the Well, not using time-related functions provided by the OS anyways. > large file compilation flags only raised the sizes to 64-bit, not the > timestamps). True. Overall I think the switch to 64-bit executables on SPARC can be justified on a case-by-case basis (or group-by-group, or all at once). Nico -- From Alan.Coopersmith@sun.com Mon Jun 2 11:46:07 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52Ik6sj022221 for ; Mon, 2 Jun 2008 11:46:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m52Ijxnk011488 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Jun 2008 02:46:06 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00G0ZMSSC700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 12:46:04 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00D2TMSRAT50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 12:46:03 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m52Ik372001612 for ; Mon, 02 Jun 2008 11:46:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1U00N01MSI0300@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 11:46:03 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1U0012RMSQ3W60@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 11:46:03 -0700 (PDT) Date: Mon, 02 Jun 2008 11:46:02 -0700 From: Alan Coopersmith Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: <20080602183811.GB2735@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Alan Coopersmith , "Richard L. Hamilton" , PSARC-ext@sun.com Message-id: <48443FEA.1040102@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> <20080602183811.GB2735@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 767 Nicolas Williams wrote: > On Mon, Jun 02, 2008 at 11:24:02AM -0700, Alan Coopersmith wrote: >>>> (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) >> Yes, the 256 FILE stdio limit is lifted in 64-bit. The other main > > Wait a minute. Our stdio does not support more than 256 open FILEs if > you use it right If you mean "does now", then yes, if you write non-portable code specific to Solaris, using the interfaces in PSARC 2006/162, then you can get stdio to open more than 256 FILEs at once. If you build 64-bit, code using standard stdio syntax common to all platforms just works without change to open > 256 FILEs. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Nicolas.Williams@sun.com Mon Jun 2 11:51:29 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52IpShI022297 for ; Mon, 2 Jun 2008 11:51:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m52IpNkk013323; Tue, 3 Jun 2008 02:51:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00F0BN1NLP00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 02 Jun 2008 11:51:23 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U0088JN1M9960@nwk-avmta-1.sfbay.Sun.COM>; Mon, 02 Jun 2008 11:51:22 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m52IpLgH005231; Mon, 02 Jun 2008 13:51:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m52IpLav005230; Mon, 02 Jun 2008 13:51:21 -0500 (CDT) Date: Mon, 02 Jun 2008 13:51:21 -0500 From: Nicolas Williams Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: <48443FEA.1040102@sun.com> To: Alan Coopersmith Cc: "Richard L. Hamilton" , PSARC-ext@sun.com Mail-followup-to: Alan Coopersmith , "Richard L. Hamilton" , PSARC-ext@sun.com Message-id: <20080602185121.GC2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> <20080602183811.GB2735@Sun.COM> <48443FEA.1040102@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 778 On Mon, Jun 02, 2008 at 11:46:02AM -0700, Alan Coopersmith wrote: > Nicolas Williams wrote: > > On Mon, Jun 02, 2008 at 11:24:02AM -0700, Alan Coopersmith wrote: > >>>> (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) > >> Yes, the 256 FILE stdio limit is lifted in 64-bit. The other main > > > > Wait a minute. Our stdio does not support more than 256 open FILEs if > > you use it right > > If you mean "does now", then yes, if you write non-portable code specific Argh. Silly typo. > to Solaris, using the interfaces in PSARC 2006/162, then you can get stdio > to open more than 256 FILEs at once. If you build 64-bit, code > using standard stdio syntax common to all platforms just works without > change to open > 256 FILEs. True enough. From carlsonj@phorcys.east.sun.com Mon Jun 2 11:54:30 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52IsTtZ022604 for ; Mon, 2 Jun 2008 11:54:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52IsNSD027466; Mon, 2 Jun 2008 19:54:27 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00105N6PIK00@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 11:54:25 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00K8RN6O8U70@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 11:54:24 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m52IksBN020153; Mon, 02 Jun 2008 14:46:54 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m52Iksui020150; Mon, 02 Jun 2008 14:46:54 -0400 (EDT) Date: Mon, 02 Jun 2008 14:46:54 -0400 From: James Carlson Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: <48443AC2.7030501@sun.com> To: Alan Coopersmith Cc: "Richard L. Hamilton" , PSARC-ext@sun.com Message-id: <18500.16414.347283.124172@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> Status: RO Content-Length: 1113 Alan Coopersmith writes: > Richard L. Hamilton wrote: > >> I can think of three main categories of capacity limits on 32-bit that > >> might > >> be higher on 64-bit: > >> * file size max of 2GB > >> * register size and usage > >> * available address space, and therefore amount that can be mmap()'d > >> at once > >> (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) > > Yes, the 256 FILE stdio limit is lifted in 64-bit. The other main It's also lifted if you call enable_extended_FILE_stdio(3C), use the extendedFILE.so.1 preload, or 'F' is used as the last character in the fopen(3C) mode string. > advantage I'm aware of is 64-bit time_t, so you can work with timestamps > outside the 1970-2038 range, which there is no way to do in 32-bit (the > large file compilation flags only raised the sizes to 64-bit, not the > timestamps). Yes; that's the biggie. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From iszczesniak@gmail.com Mon Jun 2 12:09:27 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52J9Q4m023191 for ; Mon, 2 Jun 2008 12:09:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52J8vu5003911 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Jun 2008 20:09:26 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0020BNVP3L00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 12:09:25 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00K24NVO9190@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 12:09:24 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52J5vxx012831 for ; Mon, 02 Jun 2008 19:09:24 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-228307 for PSARC-ext@sun.com; Mon, 02 Jun 2008 19:09:24 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-492986 for PSARC-ext@sun.com; Mon, 02 Jun 2008 19:09:23 +0000 (Z) Received: from wf-out-1314.google.com ([209.85.200.170] [209.85.200.170]) by relay1ib.sun.com with ESMTP id BT-MMP-3196256 for PSARC-ext@sun.com; Mon, 02 Jun 2008 19:09:23 +0000 (Z) Received: by wf-out-1314.google.com with SMTP id 27so939236wfd.17 for ; Mon, 02 Jun 2008 12:09:23 -0700 (PDT) Received: by 10.142.245.6 with SMTP id s6mr3714705wfh.141.1212433763482; Mon, 02 Jun 2008 12:09:23 -0700 (PDT) Received: by 10.143.52.6 with HTTP; Mon, 02 Jun 2008 12:09:23 -0700 (PDT) Date: Mon, 02 Jun 2008 21:09:23 +0200 From: "I. Szczesniak" Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: <18500.16414.347283.124172@gargle.gargle.HOWL> To: James Carlson Cc: Alan Coopersmith , PSARC-ext@sun.com, "Richard L. Hamilton" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=cMRzDMK1c8zYT83RQXTM3Qge7TvGzZSY8zfsyNuVCT8=; b=mbgWJSpHUM0vhd9vjevowpgk7XQzEF3RYrb8aSeQTo3ffnUwkHEOHPgOaPCg6xjHEMh/+sOOfcjXzY00aTmUo4nkE1X6z5NbmCKHqWgsZgIBgQpRY9sgfWUJCdVXxmU1gLGqTKw7SQBsk4HufT9TZgXsQTKgZYJtr2ZiHE/Eahw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=xpYV8CDDCodxMyd0v7ZK1laQo3ccjMhXRLAbcTzxyDhlZrEMh0FgrUv0rxQYxu+/KPFWkmBPt6ATW7vSpQwyUb4mmu9KRZ3YSvdqy5SweqF3m+ef8G/O6F+YJBFsDung+5AMcZrmCKA+0pq4cRd4vZLSu0EuirOIpXYa97mte+A= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.053sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> <18500.16414.347283.124172@gargle.gargle.HOWL> Status: RO Content-Length: 875 On 6/2/08, James Carlson wrote: > Alan Coopersmith writes: > > Richard L. Hamilton wrote: > > >> I can think of three main categories of capacity limits on 32-bit that > > >> might > > >> be higher on 64-bit: > > >> * file size max of 2GB > > >> * register size and usage > > >> * available address space, and therefore amount that can be mmap()'d > > >> at once > > >> (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) > > > > Yes, the 256 FILE stdio limit is lifted in 64-bit. The other main > > > It's also lifted if you call enable_extended_FILE_stdio(3C), use the > extendedFILE.so.1 preload, or 'F' is used as the last character in the > fopen(3C) mode string. FYI, enable_extended_FILE_stdio(3C) is incompatible to many applications, including coreutil. Using a FD > 256 crashes such applications. Irek From gdamore@sun.com Mon Jun 2 12:14:41 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52JEe72023338 for ; Mon, 2 Jun 2008 12:14:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m52JEevP020716 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Jun 2008 12:14:40 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00203O4GBI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 12:14:40 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00KLMO4G8Z80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 12:14:40 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m52JEdtV025727 for ; Mon, 02 Jun 2008 12:14:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1U00401NKW6E00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 12:14:39 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1U00ABUO468MH0@fe-sfbay-09.sun.com>; Mon, 02 Jun 2008 12:14:31 -0700 (PDT) Date: Mon, 02 Jun 2008 12:14:12 -0700 From: "Garrett D'Amore" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48443BC3.1010802@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: Darren J Moffat , Joseph Kowalski , John Plocher , PSARC-ext@sun.com Message-id: <48444684.4010209@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2959 Bart Smaalders wrote: > Garrett D'Amore wrote: > >> My personal preference, for now, would be to deliver *both* 32- and >> 64-bit versions of the applications for both SPARC and x86, but >> deliver the 64-bit versions in a separate path (/usr/bin/sparcv9 and >> /usr/bin/amd64 or somesuch), so that end users can just adjust their >> $PATH appropriately if they know they need or want 64-bit capable >> programs (I think for the vast majority of users, this will not be >> necessary.) >> >> This has the added advantage of minimizing the ARC "impact" of this, >> by not changing the "default" version of the tools right now. (And >> doesn't preclude making such a change later, particularly if at some >> point we decide we can stop supporting 32-bit-only processors, which >> I imagine we might do some number of years in the future.) > > Why should we continue to deliver a 32 bit version of a command, if today > we always exec the 64 bit varient? Anything that goes through isaexec > today should be 64 bit only on SPARC. The fact that we still use > isaexec on > SPARC at all is a bug. Agreed, if it is true that we always use isaexec. But, are there cases where a separate 32-bit version is useful on SPARC for reasons other than described here (or where we don't "always use isaexec")? (For example, is it true that a 64-bit version never incurs any performance regression? Or is there ever a reason to use a 32-bit program to validate that a program -- script or otherwise -- will function properly on 32-bit-only architectures?) > > x86 will for now need to deliver both 32 and 64 bit binaries. If > you're worried > about the performance issues involved w/ isaexec, then let's design > something > better.... but have the user adjust their path is a complete > non-starter and > we still need isaexec for the correctness cases (proc tools, etc). Yes, isaexec is needed for correctness, but its not used on any performance critical paths, and remains, IMO, an ugly hack rather than an elegant solution. I'm not adverse to designing something better (I like the idea), but my first gut instinct is "not this case". Modifying $PATH is a crummy solution, I agree, but as an interim hack to enable delivery for the few users that need the 64-bit semantics (and I think the number that actually do need them for these apps is almost vanishingly small) they have a workaround until we can come up with something better. (I'm also looking for a way to allow this case to proceed forward, without requiring it to block on a larger set of architectural problems that the project team is probably ill-equipped to solve.) (As far as "something better", I think I prefer something along the lines of how AFS handles it, where $VARIABLE could be used within a symbolic link -- the kernel expands the variable when following the symlink. But we shouldn't try to design the solution here, I think.) -- Garrett From Nicolas.Williams@sun.com Mon Jun 2 12:25:29 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52JPTlL023380 for ; Mon, 2 Jun 2008 12:25:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m52JPRnR023705; Mon, 2 Jun 2008 12:25:27 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0020BOMFTG00@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 12:25:27 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00K95OME8U90@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 12:25:26 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m52JPPeN005250; Mon, 02 Jun 2008 14:25:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m52JPPtk005249; Mon, 02 Jun 2008 14:25:25 -0500 (CDT) Date: Mon, 02 Jun 2008 14:25:24 -0500 From: Nicolas Williams Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48444684.4010209@sun.com> To: "Garrett D'Amore" Cc: Bart Smaalders , Darren J Moffat , Joseph Kowalski , John Plocher , PSARC-ext@sun.com Mail-followup-to: Garrett D'Amore , Bart Smaalders , Darren J Moffat , Joseph Kowalski , John Plocher , PSARC-ext@sun.com Message-id: <20080602192524.GD2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48444684.4010209@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2001 On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote: > Yes, isaexec is needed for correctness, but its not used on any > performance critical paths, and remains, IMO, an ugly hack rather than > an elegant solution. isaexec handling could move into the kernel if it had to to avoid the additional exec(). > I'm not adverse to designing something better (I like the idea), but my > first gut instinct is "not this case". Right. Well, maybe, now that it's a full case I think isaexec optimization could certainly be on the table. > Modifying $PATH is a crummy solution, I agree, but as an interim hack to Not only crummy. We won't do it. That ship has sailed. > enable delivery for the few users that need the 64-bit semantics (and I > think the number that actually do need them for these apps is almost > vanishingly small) they have a workaround until we can come up with > something better. I'd rather we come up with something better. PATH monkeying should be seen as completely unacceptable here. > (I'm also looking for a way to allow this case to proceed forward, > without requiring it to block on a larger set of architectural problems > that the project team is probably ill-equipped to solve.) It's a full case now. > (As far as "something better", I think I prefer something along the > lines of how AFS handles it, where $VARIABLE could be used within a > symbolic link -- the kernel expands the variable when following the > symlink. But we shouldn't try to design the solution here, I think.) The ELF exec handler in the kernel could find the conditional logic to evaluate and tokens to expand, and just do it. This would be much safer than modifying the semantics of symlinks. And isaexec would remain, but the extra exec() would be avoided. But one step at a time. This smacks me as premature optimization (even though the extra exec() is wasteful -- the point it is that optimizing isaexec now is premature for this discussion). Nico -- From carlsonj@phorcys.east.sun.com Mon Jun 2 12:39:34 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52JdXfk023585 for ; Mon, 2 Jun 2008 12:39:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52JdSsb015801; Mon, 2 Jun 2008 20:39:31 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0030LP9TE500@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 12:39:29 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00K33P9S8UA0@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 12:39:29 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m52JGxR9020375; Mon, 02 Jun 2008 15:16:59 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m52JGxef020372; Mon, 02 Jun 2008 15:16:59 -0400 (EDT) Date: Mon, 02 Jun 2008 15:16:59 -0400 From: James Carlson Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: To: "I. Szczesniak" Cc: Alan Coopersmith , PSARC-ext@sun.com, "Richard L. Hamilton" Message-id: <18500.18219.433958.307965@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> <18500.16414.347283.124172@gargle.gargle.HOWL> Status: RO Content-Length: 989 I. Szczesniak writes: > On 6/2/08, James Carlson wrote: > > It's also lifted if you call enable_extended_FILE_stdio(3C), use the > > extendedFILE.so.1 preload, or 'F' is used as the last character in the > > fopen(3C) mode string. > > FYI, enable_extended_FILE_stdio(3C) is incompatible to many > applications, including coreutil. Using a FD > 256 crashes such > applications. "Coreutil"? As in GNU coreutils? If there's a problem here, and it's not just broken code in the application, then filing bugs would help. I searched for, but did not find, any references to this problem either at any external site or in the bug databases. In any event, I don't think whether or not the GNU coreutils work right is itself architectural. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From roland.mainz@nrubsig.org Mon Jun 2 12:41:05 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52Jf4kL023634 for ; Mon, 2 Jun 2008 12:41:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m52JevBx000651; Tue, 3 Jun 2008 03:40:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00307PC8H700@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 12:40:56 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00K9KPC88V90@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 12:40:56 -0700 (PDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52JUR5e025209; Mon, 02 Jun 2008 19:40:55 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay12i.sun.com with ESMTP id BT-MMP-229866; Mon, 02 Jun 2008 19:40:55 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-10875836; Mon, 02 Jun 2008 19:40:55 +0000 (Z) Received: from mail-in-17.arcor-online.net ([151.189.21.57] [151.189.21.57]) by relay1i.sun.com with ESMTP id BT-MMP-3378627; Mon, 02 Jun 2008 19:40:55 +0000 (Z) Received: from mail-in-16-z2.arcor-online.net (mail-in-16-z2.arcor-online.net [151.189.8.33]) by mail-in-17.arcor-online.net (Postfix) with ESMTP id A804B2BC6DF; Mon, 02 Jun 2008 21:40:53 +0200 (CEST) Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43]) by mail-in-16-z2.arcor-online.net (Postfix) with ESMTP id B056D2543D8; Mon, 02 Jun 2008 21:40:51 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-021-216.pools.arcor-ip.net [84.59.21.216]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id D54F0312763; Mon, 02 Jun 2008 21:40:50 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m52JekrF000714; Mon, 02 Jun 2008 21:40:47 +0200 (CEST) Date: Mon, 02 Jun 2008 21:40:46 +0200 From: Roland Mainz Subject: Full case ? / was: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: Nicolas Williams Cc: "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Bart Smaalders , Joseph Kowalski Message-id: <48444CBE.89BB05C0@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/7325/Mon Jun 2 15:45:22 2008 on mail-in-03.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.049sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48444684.4010209@sun.com> <20080602192524.GD2735@Sun.COM> Status: RO Content-Length: 362 Nicolas Williams wrote: > On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote: [snip] > It's a full case now. Who or what decided that ? IMO this still fast-track. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From Nicolas.Williams@sun.com Mon Jun 2 12:43:00 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52JgxQ4023668 for ; Mon, 2 Jun 2008 12:43:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52Jgs7N017329; Mon, 2 Jun 2008 20:42:56 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00K01PFJNA00@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 13:42:55 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00DX5PFIAYB0@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 13:42:54 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m52Jgrpf005280; Mon, 02 Jun 2008 14:42:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m52Jgq4J005279; Mon, 02 Jun 2008 14:42:52 -0500 (CDT) Date: Mon, 02 Jun 2008 14:42:52 -0500 From: Nicolas Williams Subject: Re: Full case ? / was: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <48444CBE.89BB05C0@nrubsig.org> To: Roland Mainz Cc: "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Bart Smaalders , Joseph Kowalski Mail-followup-to: Roland Mainz , Garrett D'Amore , PSARC-ext@sun.com, John Plocher , Bart Smaalders , Joseph Kowalski Message-id: <20080602194252.GG2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48444684.4010209@sun.com> <20080602192524.GD2735@Sun.COM> <48444CBE.89BB05C0@nrubsig.org> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 279 On Mon, Jun 02, 2008 at 09:40:46PM +0200, Roland Mainz wrote: > Nicolas Williams wrote: > > On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote: > [snip] > > It's a full case now. > > Who or what decided that ? IMO this still fast-track. Darren Moffat derailed it. From roland.mainz@nrubsig.org Mon Jun 2 12:52:19 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52JqIhb023890 for ; Mon, 2 Jun 2008 12:52:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m52JqFqL063322; Mon, 2 Jun 2008 13:52:15 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00M03PV24O00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 02 Jun 2008 12:52:14 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U008RJPV29880@nwk-avmta-1.sfbay.Sun.COM>; Mon, 02 Jun 2008 12:52:14 -0700 (PDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52JqDiX019734; Mon, 02 Jun 2008 19:52:13 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay21i.sun.com with ESMTP id BT-MMP-1212624; Mon, 02 Jun 2008 19:52:13 +0000 (Z) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-10765026; Mon, 02 Jun 2008 19:52:12 +0000 (Z) Received: from mail-in-02.arcor-online.net ([151.189.21.42] [151.189.21.42]) by relay24i.sun.com with ESMTP id BT-MMP-13373100; Mon, 02 Jun 2008 19:52:12 +0000 (Z) Received: from mail-in-06-z2.arcor-online.net (mail-in-06-z2.arcor-online.net [151.189.8.18]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 619EA32E9F2; Mon, 02 Jun 2008 21:52:11 +0200 (CEST) Received: from mail-in-17.arcor-online.net (mail-in-17.arcor-online.net [151.189.21.57]) by mail-in-06-z2.arcor-online.net (Postfix) with ESMTP id 4EAC0ABAA1; Mon, 02 Jun 2008 21:52:11 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-021-216.pools.arcor-ip.net [84.59.21.216]) by mail-in-17.arcor-online.net (Postfix) with ESMTP id B8FA72BC93E; Mon, 02 Jun 2008 21:52:10 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m52Jq7Us000721; Mon, 02 Jun 2008 21:52:07 +0200 (CEST) Date: Mon, 02 Jun 2008 21:52:06 +0200 From: Roland Mainz Subject: Re: Full case ? / was: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: Nicolas Williams , Darren Reed Cc: "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Bart Smaalders , Joseph Kowalski Message-id: <48444F66.D624C00D@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on mail-in-17.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.158sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48444684.4010209@sun.com> <20080602192524.GD2735@Sun.COM> <48444CBE.89BB05C0@nrubsig.org> <20080602194252.GG2735@Sun.COM> Status: RO Content-Length: 1474 Nicolas Williams wrote: > On Mon, Jun 02, 2008 at 09:40:46PM +0200, Roland Mainz wrote: > > Nicolas Williams wrote: > > > On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote: > > [snip] > > > It's a full case now. > > > > Who or what decided that ? IMO this still fast-track. > > Darren Moffat derailed it. And I disagree with Darren. Originally his was a simple engineering issue until other people mutated the RFE. The original idea to get some improvements (by shipping GNU coreutils and "bash" as 64bit applications by default on 64bit-only platforms (which means SPARC and two Solaris ports which shall-not-be-named right now)), including: -- snip -- - No problem with dates >= 2030 (64bit |time_t|) - High-resolution timestamps by default - Stack would be non-executable by default - ARG_MAX would be larger (twice the size), therefore allowing applications to deal with much more data (note this extra memory is mapped via |mmap()|-like calls and only reserves the size, not actually allocate it (reserved address space != real memory usage)). - "bash" supports arrays and it would be nice that we don't limit the array content to 2GB -- snip -- Please tell me why this requires a FULL ARC case. This isn't normal anymore. Darren: Can you please revoke the derail ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From Mark.Carlson@sun.com Mon Jun 2 12:53:05 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52Jr5Hn023928 for ; Mon, 2 Jun 2008 12:53:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m52Jr3sB007512 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Jun 2008 12:53:05 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00M0TPWF7Q00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 12:53:03 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U008TZPWF9880@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 12:53:03 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52Jr3Tk010136 for ; Mon, 02 Jun 2008 19:53:03 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1U00F01PKB7I00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 13:53:03 -0600 (MDT) Received: from Macintosh-205.local ([71.237.94.98]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1U005PNPWAL500@mail-amer.sun.com>; Mon, 02 Jun 2008 13:52:59 -0600 (MDT) Date: Mon, 02 Jun 2008 13:52:58 -0600 From: "Mark A. Carlson" Subject: Re: Full case ? / was: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <20080602194252.GG2735@Sun.COM> Sender: Mark.Carlson@sun.com To: Roland Mainz , "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Bart Smaalders , Joseph Kowalski Message-id: <48444F9A.9010104@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vAA0lbB7+IT+SyTL6Lm+UQ)" X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48444684.4010209@sun.com> <20080602192524.GD2735@Sun.COM> <48444CBE.89BB05C0@nrubsig.org> <20080602194252.GG2735@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 3038 This is a multi-part message in MIME format. --Boundary_(ID_vAA0lbB7+IT+SyTL6Lm+UQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Someone needs to update the IAM file then as it currently is a fast track timing out 6/6. Regardless, I have asked for a short time to discuss this case during ARC business Wednesday so we can decide (off list!) how to deal with this case. Again, we do NOT need to derail cases to have these discussions and I *thought* we agreed to do this when the threads got long an heated as this one seem to be. IMHO, any further posts should cease and interested parties should show up for the PSARC discussion. -- mark Nicolas Williams wrote: > On Mon, Jun 02, 2008 at 09:40:46PM +0200, Roland Mainz wrote: > >> Nicolas Williams wrote: >> >>> On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote: >>> >> [snip] >> >>> It's a full case now. >>> >> Who or what decided that ? IMO this still fast-track. >> > > Darren Moffat derailed it. > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > --Boundary_(ID_vAA0lbB7+IT+SyTL6Lm+UQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Someone needs to update the IAM file then as it currently is a
fast track timing out 6/6.

Regardless, I have asked for a short time to discuss this case
during ARC business Wednesday so we can decide (off list!) how
to deal with this case.

Again, we do NOT need to derail cases to have these discussions
and I *thought* we agreed to do this when the threads got long
an heated as this one seem to be.

IMHO, any further posts should cease and interested parties
should show up for the PSARC discussion.

-- mark

Nicolas Williams wrote: 
On Mon, Jun 02, 2008 at 09:40:46PM +0200, Roland Mainz wrote:
  
Nicolas Williams wrote:
    
On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote:
      
[snip]
    
It's a full case now.
      
Who or what decided that ? IMO this still fast-track.
    

Darren Moffat derailed it.
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
--Boundary_(ID_vAA0lbB7+IT+SyTL6Lm+UQ)-- From roland.mainz@nrubsig.org Mon Jun 2 13:01:10 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52K19n2024487 for ; Mon, 2 Jun 2008 13:01:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m52K11i6007269; Tue, 3 Jun 2008 04:01:04 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00M1TQ9P1U00@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 14:01:01 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00DNCQ9PAWD0@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 14:01:01 -0600 (MDT) Received: from relay18i.sun.com (ip128.net129179-4.block1.us.syntegra.com [129.179.4.128]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52JuAmX016109; Mon, 02 Jun 2008 20:01:01 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay18i.sun.com with ESMTP id BT-MMP-230628; Mon, 02 Jun 2008 20:01:01 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-10911556; Mon, 02 Jun 2008 20:01:00 +0000 (Z) Received: from mail-in-11.arcor-online.net ([151.189.21.51] [151.189.21.51]) by relay1ib.sun.com with ESMTP id BT-MMP-3223012; Mon, 02 Jun 2008 20:01:00 +0000 (Z) Received: from mail-in-06-z2.arcor-online.net (mail-in-06-z2.arcor-online.net [151.189.8.18]) by mail-in-11.arcor-online.net (Postfix) with ESMTP id 9437111CFD; Mon, 02 Jun 2008 22:00:58 +0200 (CEST) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-06-z2.arcor-online.net (Postfix) with ESMTP id 6F60EABAB1; Mon, 02 Jun 2008 22:00:58 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-021-216.pools.arcor-ip.net [84.59.21.216]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id 4477128ABB2; Mon, 02 Jun 2008 22:00:58 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m52K0tdx000727; Mon, 02 Jun 2008 22:00:56 +0200 (CEST) Date: Mon, 02 Jun 2008 22:00:55 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: Nicolas Williams Cc: "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Bart Smaalders , Joseph Kowalski Message-id: <48445177.7AB787D1@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/7325/Mon Jun 2 15:45:22 2008 on mail-in-07.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.090sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48444684.4010209@sun.com> <20080602192524.GD2735@Sun.COM> Status: RO Content-Length: 2625 Nicolas Williams wrote: > On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote: > > Yes, isaexec is needed for correctness, but its not used on any > > performance critical paths, and remains, IMO, an ugly hack rather than > > an elegant solution. > > isaexec handling could move into the kernel if it had to to avoid the > additional exec(). |isaexec()| cannot be moved into the kernel unless you can implement CR#6474270 ("isaexec and magical builds" - http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270) from the kernel, too. [snip] > > (I'm also looking for a way to allow this case to proceed forward, > > without requiring it to block on a larger set of architectural problems > > that the project team is probably ill-equipped to solve.) > > It's a full case now. And I disagree. The original idea was to get rid of some limits in some tools, not boil the ocean or start becoming a politician (and half of the emails I got via PM strongly indicate that the mutations on top of the original idea are political issues which should be handled via ogb-discuss@opensolaris.org and not PSARC). > > (As far as "something better", I think I prefer something along the > > lines of how AFS handles it, where $VARIABLE could be used within a > > symbolic link -- the kernel expands the variable when following the > > symlink. But we shouldn't try to design the solution here, I think.) > > The ELF exec handler in the kernel could find the conditional logic to > evaluate and tokens to expand, and just do it. This would be much safer > than modifying the semantics of symlinks. And isaexec would remain, but > the extra exec() would be avoided. As said it wouldn't work (see above). And the |exec()| overhead for _shell_ interpreters like "ksh93" is usually canceled out by using builtin commands and avoiding that subshells |fork()| which more or less eliminates gdamore's complains about isaexec in this case (and "yes" - we did benchmark that). For "bash" it may be slighty different since it |fork()|+|exec()|s a lot more than ksh93 but I still think it won't harm users a lot. > But one step at a time. This smacks me as premature optimization (even > though the extra exec() is wasteful -- the point it is that optimizing > isaexec now is premature for this discussion). Right. And please don't implement anything which prevents us from implementing CR#6474270 ("isaexec and magical builds"). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From Richard.Matthews@sun.com Mon Jun 2 13:03:51 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52K3onu024689 for ; Mon, 2 Jun 2008 13:03:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m52K3m1k008443 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Jun 2008 04:03:49 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00003QEC6A00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 13:03:48 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00802QEB97C0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 13:03:48 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52K3llZ026281 for ; Mon, 02 Jun 2008 20:03:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1U00601PJDKW00@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 14:03:47 -0600 (MDT) Received: from [129.152.9.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1U000X6QE1AR50@mail-amer.sun.com>; Mon, 02 Jun 2008 14:03:40 -0600 (MDT) Date: Mon, 02 Jun 2008 15:03:37 -0500 From: Rick Matthews Subject: Re: Full case ? / was: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <20080602194252.GG2735@Sun.COM> Sender: Richard.Matthews@sun.com To: Roland Mainz , "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Bart Smaalders , Joseph Kowalski Reply-to: Richard.Matthews@sun.com Message-id: <48445219.3030704@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_nBP+45arIcEnB5xIlPk5wg)" X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48444684.4010209@sun.com> <20080602192524.GD2735@Sun.COM> <48444CBE.89BB05C0@nrubsig.org> <20080602194252.GG2735@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 3551 This is a multi-part message in MIME format. --Boundary_(ID_nBP+45arIcEnB5xIlPk5wg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Nicolas Williams wrote: > On Mon, Jun 02, 2008 at 09:40:46PM +0200, Roland Mainz wrote: > >> Nicolas Williams wrote: >> >>> On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote: >>> >> [snip] >> >>> It's a full case now. >>> >> Who or what decided that ? IMO this still fast-track. >> > > Darren Moffat derailed it. > In reviewing the email trail (which is getting rather long), Darren said derail, then said "at least a fast track". I am going to assume Darren is OK with a fast track until then. I propose we take no more than 5 minutes discussing this fast track at Weds. meeting. During this 5 minutes, ample time will be allowed to derail to a full case, if need be. Perhaps we should table further discussion until Wednesday. -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- --Boundary_(ID_nBP+45arIcEnB5xIlPk5wg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Nicolas Williams wrote: 
On Mon, Jun 02, 2008 at 09:40:46PM +0200, Roland Mainz wrote:
  
Nicolas Williams wrote:
    
On Mon, Jun 02, 2008 at 12:14:12PM -0700, Garrett D'Amore wrote:
      
[snip]
    
It's a full case now.
      
Who or what decided that ? IMO this still fast-track.
    

Darren Moffat derailed it.
In reviewing the email trail (which is getting rather long), Darren said derail, then
said "at least a fast track". I am going to assume Darren is OK with a fast track until
then. I propose we take no more than 5 minutes discussing this fast track at Weds.
meeting. During this 5 minutes, ample time will be allowed to derail to a full
case, if need be.

Perhaps we should table further discussion until Wednesday. 

-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------
--Boundary_(ID_nBP+45arIcEnB5xIlPk5wg)-- From Nicolas.Williams@sun.com Mon Jun 2 13:07:30 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52K7TkV024921 for ; Mon, 2 Jun 2008 13:07:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52K7MLm029545; Mon, 2 Jun 2008 21:07:24 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00405QKCMX00@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 13:07:24 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00K9YQKB8SB0@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 13:07:23 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m52K7M8D005311; Mon, 02 Jun 2008 15:07:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m52K7MfU005310; Mon, 02 Jun 2008 15:07:22 -0500 (CDT) Date: Mon, 02 Jun 2008 15:07:21 -0500 From: Nicolas Williams Subject: Re: Full case ? / was: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <48445219.3030704@Sun.COM> To: Rick Matthews Cc: Roland Mainz , "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Bart Smaalders , Joseph Kowalski Mail-followup-to: Rick Matthews , Roland Mainz , Garrett D'Amore , PSARC-ext@sun.com, John Plocher , Bart Smaalders , Joseph Kowalski Message-id: <20080602200721.GJ2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48444684.4010209@sun.com> <20080602192524.GD2735@Sun.COM> <48444CBE.89BB05C0@nrubsig.org> <20080602194252.GG2735@Sun.COM> <48445219.3030704@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 531 On Mon, Jun 02, 2008 at 03:03:37PM -0500, Rick Matthews wrote: > In reviewing the email trail (which is getting rather long), Darren > said derail, then said "at least a fast track". I am going to assume > Darren is OK with a fast track until then. I propose we take no more > than 5 minutes discussing this fast track at Weds. meeting. During > this 5 minutes, ample time will be allowed to derail to a full case, > if need be. Ah, indeed, Darren did not derail the fasttrack, but the self-approval. Thanks for the correction. From Joerg.Schilling@fokus.fraunhofer.de Mon Jun 2 13:12:51 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52KCorc025380 for ; Mon, 2 Jun 2008 13:12:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52KChog002020; Mon, 2 Jun 2008 21:12:48 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0010VQTB7K00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 02 Jun 2008 13:12:47 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U008LVQTA9ED0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 02 Jun 2008 13:12:47 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52KCjmK014901; Mon, 02 Jun 2008 20:12:46 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-231403; Mon, 02 Jun 2008 20:12:45 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-10931776; Mon, 02 Jun 2008 20:12:44 +0000 (Z) Received: from mailgwb1.fraunhofer.de ([153.96.87.18] [153.96.87.18]) by relay1i.sun.com with ESMTP id BT-MMP-3494654; Mon, 02 Jun 2008 20:12:44 +0000 (Z) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id m52K8TFl000834; Mon, 02 Jun 2008 22:08:29 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m52K8T6V000822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 02 Jun 2008 22:08:29 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m52K8Sv7029070; Mon, 02 Jun 2008 22:08:28 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 02 Jun 2008 22:08:28 +0200 Date: Mon, 02 Jun 2008 22:08:25 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: <48443AC2.7030501@sun.com> To: rlhamil@smart.net, alan.coopersmith@sun.com Cc: PSARC-ext@sun.com Message-id: <48445339.JfUEESIFoaUlWOCj%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.369sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 02 Jun 2008 20:08:28.0921 (UTC) FILETIME=[6C59CE90:01C8C4EC] Status: RO Content-Length: 1737 Alan Coopersmith wrote: > Richard L. Hamilton wrote: > >> I can think of three main categories of capacity limits on 32-bit that > >> might > >> be higher on 64-bit: > >> * file size max of 2GB > >> * register size and usage > >> * available address space, and therefore amount that can be mmap()'d > >> at once > >> (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) > > Yes, the 256 FILE stdio limit is lifted in 64-bit. The other main > advantage I'm aware of is 64-bit time_t, so you can work with timestamps > outside the 1970-2038 range, which there is no way to do in 32-bit (the > large file compilation flags only raised the sizes to 64-bit, not the > timestamps). The main problem with the Solaris largefile compile environment is that it forgot to include time stamps. It would be simple to add another gettimeofday().... and time_t implementation with e.g. -DLARGETIME It would unfortunately only work if there would be another stat(2) interface for this purpose as this would affect the layout of struct stat. If this is not done, we would need 64 bit versions of all programs that call stat(2) on files that may have time stamps outside the permitted range for a 32 bit program. This may be any file from NFS or PCFS, so this are many/all programs using stat(2) and even important programs like find(1) are still missing from the list of 64 bit programs on Solaris. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From roland.mainz@nrubsig.org Mon Jun 2 13:20:28 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52KKRlr025654 for ; Mon, 2 Jun 2008 13:20:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52KK5JW005227; Mon, 2 Jun 2008 21:20:23 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00001R5ZEO00@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 14:20:23 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00MK6R5ZTF00@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 14:20:23 -0600 (MDT) Received: from relay16i.sun.com (ip126.net129179-4.block1.us.syntegra.com [129.179.4.126]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52KKMl0029776; Mon, 02 Jun 2008 20:20:22 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay16i.sun.com with ESMTP id BT-MMP-231604; Mon, 02 Jun 2008 20:20:22 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-618931; Mon, 02 Jun 2008 20:20:22 +0000 (Z) Received: from mail-in-14.arcor-online.net ([151.189.21.54] [151.189.21.54]) by relay1ib.sun.com with ESMTP id BT-MMP-3216713; Mon, 02 Jun 2008 20:20:21 +0000 (Z) Received: from mail-in-18-z2.arcor-online.net (mail-in-18-z2.arcor-online.net [151.189.8.35]) by mail-in-14.arcor-online.net (Postfix) with ESMTP id 540B218786E; Mon, 02 Jun 2008 22:20:19 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-18-z2.arcor-online.net (Postfix) with ESMTP id 330015102D2; Mon, 02 Jun 2008 22:20:19 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-021-216.pools.arcor-ip.net [84.59.21.216]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 3F3D48C462; Mon, 02 Jun 2008 22:20:18 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m52KKFEP000733; Mon, 02 Jun 2008 22:20:16 +0200 (CEST) Date: Mon, 02 Jun 2008 22:20:15 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Bart Smaalders , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <484455FF.735C64F@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/7325/Mon Jun 2 15:45:22 2008 on mail-in-12.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.100sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> Status: RO Content-Length: 3493 Garrett D'Amore wrote: > Bart Smaalders wrote: > > Darren J Moffat wrote: > >> I'm derailing this automatic approval. I want at least a fast-track > >> that explains why the asymetry between SPARC and x86 is actually > >> useful in addition to what Joe asked for. > > > > Because we support x86 machines that don't implement 64 bit support? > > The same reason we ship a 32 bit and a 64 bit x86 kernel? But |isaexec()| won't help you since it cuts stuff like |ARG_MAX| to the 32bit limit. And the original idea was to do the change _only_ for machines which are native 64bit platforms (e.g. SPARC and two Solaris ports which shall-not-be-named here) and not to try to boil the ocean by enforcing the change for all platforms. > >> I think this should actually be a full case rather than a fast-track > >> given this would be a significant architectural change. As Joe said > >> the GNU part is irrelevant here what is relevant is the change in > >> direction. > > > > Whether a particular executable is delivered as a 32 bit binary, 64 > > bit binary > > or shell script/java/python.... seems more of an implementation detail > > rather > > than an architecture change. > > > > I assume that the proposal here is to deliver 64 bit versions of these > > commands > > on sparc, and both 32 and 64 bit versions on x86. > > > > My question here is whether there is a plan about what to do w/ 32bit > > only (x86) systems in regards to whatever limit this change avoids.... > > I think the above question (the behavioral difference) is one that > really needs to be addressed. It may be that the answer is that we > don't care about the limit on 32-bit only systems, but what are we going > to do for 64-bit-capable x86 boxes? I am pretty unhappy with the > current isaexec() solution - the extra fork/exec combo seems > "unfortunate", particularly for utilities that might be executed heavily > in embedded scripts. (The shell, and coreutils, seems to fall into this > category.) Please remove the shells from the list. As I explained earlier (and in the original ksh93-integration ARC case, and via IRC, and via email etc.) the extra |exec()| is usually (except for cases like $ /usr/bin/ksh93 -c 'true' #) canceled-out when the shell uses builtin commands or avoids calling |fork()| for subshells (that was at least the case of ksh93). "bash" may slightly different but it's still something which will IMO not hurt compared to _other_ stuff in "bash" which currently goes badly wrong (e.g. default build options). Just by fixing that we win more than you loose via "isaexec". > My personal preference, for now, would be to deliver *both* 32- and > 64-bit versions of the applications for both SPARC and x86, but deliver > the 64-bit versions in a separate path (/usr/bin/sparcv9 and > /usr/bin/amd64 or somesuch), so that end users can just adjust their > $PATH appropriately if they know they need or want 64-bit capable > programs (I think for the vast majority of users, this will not be > necessary.) Groan... and noone will find these binaries. And /usr/bin/${MACH64}/ is not an ARC'ed interface either... ... what about a compromise: Use 64bit versions of these utilities on 64bit-only kernels by default and use /usr/bin/64/ on platoforms like Solaris/x86. Would that be acceptable for you? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From gdamore@sun.com Mon Jun 2 13:24:07 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52KO6Ga025689 for ; Mon, 2 Jun 2008 13:24:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52KO4SU006760 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Jun 2008 21:24:05 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0021DRC4C200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 13:24:04 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U008M4RC397D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 13:24:03 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m52KNwrf004722 for ; Mon, 02 Jun 2008 13:24:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1U00601R2BB100@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Jun 2008 13:24:01 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1U007N1RBWJHG0@fe-sfbay-09.sun.com>; Mon, 02 Jun 2008 13:23:57 -0700 (PDT) Date: Mon, 02 Jun 2008 13:23:38 -0700 From: "Garrett D'Amore" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <484455FF.735C64F@nrubsig.org> Sender: Garrett.Damore@sun.com To: Roland Mainz Cc: Bart Smaalders , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <484456CA.1070403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <484455FF.735C64F@nrubsig.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 564 Roland Mainz wrote: > Groan... and noone will find these binaries. And /usr/bin/${MACH64}/ is > not an ARC'ed interface either... > ... what about a compromise: Use 64bit versions of these utilities on > 64bit-only kernels by default and use /usr/bin/64/ on platoforms like > Solaris/x86. Would that be acceptable for you? > This might be acceptable, particularly if there are no other behavioral side effects. However, lets wait for the discussion at PSARC on Wednesday. Will you be able to dial in then? -- Garrett > ---- > > Bye, > Roland > > From bart.smaalders@sun.com Mon Jun 2 13:39:41 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52Kde9p025819 for ; Mon, 2 Jun 2008 13:39:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52KdY8Y012953; Mon, 2 Jun 2008 21:39:37 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00609S1Z0800@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 13:39:35 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00KMZS1Z8OC0@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 13:39:35 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m52KdZjF020777; Mon, 02 Jun 2008 20:39:35 +0000 (GMT) Date: Mon, 02 Jun 2008 13:39:35 -0700 From: Bart Smaalders Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <484455FF.735C64F@nrubsig.org> To: Roland Mainz Cc: "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <48445A87.9080704@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <484455FF.735C64F@nrubsig.org> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 745 Roland Mainz wrote: > Groan... and noone will find these binaries. And /usr/bin/${MACH64}/ is > not an ARC'ed interface either... > ... what about a compromise: Use 64bit versions of these utilities on > 64bit-only kernels by default and use /usr/bin/64/ on platoforms like > Solaris/x86. Would that be acceptable for you? Roland - If it's worthwhile switching to 64 bit versions for SPARC, what reason is there to not use isaexec for x86? E.g. - what problem is worth fixing on SPARC by switching to 64 bit, but not worth fixing on x86 because it requires isaexec? - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From roland.mainz@nrubsig.org Mon Jun 2 13:42:39 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52Kgdm6025934 for ; Mon, 2 Jun 2008 13:42:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m52Kgc6T021904; Mon, 2 Jun 2008 13:42:39 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0061DS725100@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 13:42:38 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00KMHS718SD0@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 13:42:37 -0700 (PDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52Kd9qV021751; Mon, 02 Jun 2008 20:42:37 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay23i.sun.com with ESMTP id BT-MMP-341672; Mon, 02 Jun 2008 20:42:37 +0000 (Z) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-10847883; Mon, 02 Jun 2008 20:42:36 +0000 (Z) Received: from mail-in-05.arcor-online.net ([151.189.21.45] [151.189.21.45]) by relay24i.sun.com with ESMTP id BT-MMP-13473435; Mon, 02 Jun 2008 20:42:36 +0000 (Z) Received: from mail-in-12-z2.arcor-online.net (mail-in-12-z2.arcor-online.net [151.189.8.29]) by mail-in-05.arcor-online.net (Postfix) with ESMTP id 43258183748; Mon, 02 Jun 2008 22:42:35 +0200 (CEST) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-12-z2.arcor-online.net (Postfix) with ESMTP id 2C418279437; Mon, 02 Jun 2008 22:42:35 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-021-216.pools.arcor-ip.net [84.59.21.216]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 4990B36E863; Mon, 02 Jun 2008 22:42:34 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m52KgVKc000739; Mon, 02 Jun 2008 22:42:32 +0200 (CEST) Date: Mon, 02 Jun 2008 22:42:31 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] Sender: gisburn@jupiterb48.nrubsig.org To: Bart Smaalders Cc: "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <48445B37.C007CCFE@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/7325/Mon Jun 2 15:45:22 2008 on mail-in-02.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=1.4/5.0, scanned in 0.395sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> Status: RO Content-Length: 4055 Bart Smaalders wrote: > Garrett D'Amore wrote: > > My personal preference, for now, would be to deliver *both* 32- and > > 64-bit versions of the applications for both SPARC and x86, but deliver > > the 64-bit versions in a separate path (/usr/bin/sparcv9 and > > /usr/bin/amd64 or somesuch), so that end users can just adjust their > > $PATH appropriately if they know they need or want 64-bit capable > > programs (I think for the vast majority of users, this will not be > > necessary.) > > > > This has the added advantage of minimizing the ARC "impact" of this, by > > not changing the "default" version of the tools right now. (And doesn't > > preclude making such a change later, particularly if at some point we > > decide we can stop supporting 32-bit-only processors, which I imagine we > > might do some number of years in the future.) > > Why should we continue to deliver a 32 bit version of a command, if today > we always exec the 64 bit varient? Anything that goes through isaexec > today should be 64 bit only on SPARC. The fact that we still use isaexec on > SPARC at all is a bug. Slightly offtopic: One case was ksh93 where we _explicitly_ ship 32bit and 64bit vesions on both SPARC and x86 via "isaexec" (even against gdamore's counsel) because ksh93 supports a plugin API (and these plugin may need other libraries which may only be available as 32bit versions), ksh93's ability to handle _vast_ amounts of data in variable trees and arrays (therefore the 64bit version being the default on 64bit platforms) and because we want to make APIs like libshell and libast open in the future (first for ARC contracts and then gradually increasing the stability level) and that requires both 32bit+64bit versions, too. However this was a _special_ case and we did lots of research and benchmarking for this topic to make sure we don't run into any problems. This 32bit+64bit support on 64bit-only platforms should IMO really be the exception and not the default. > x86 will for now need to deliver both 32 and 64 bit binaries. If you're > worried > about the performance issues involved w/ isaexec, then let's design > something > better.... but have the user adjust their path is a complete non-starter and > we still need isaexec for the correctness cases (proc tools, etc). Right now "isaexec" isn't that bad. However the extra |exec()| becomes an issue in two scenarios: 1. Tiny application with very small runtime (e.g. GNU "echo") 2. Machine with many CPUs - |exec()| must tear down the address space and makes crosscalls to all other CPUs... which will be a problem for the 256CPU Niagara2+ machine... and even more a problem when I read TheRegister.co.uk's article (http://www.theregister.co.uk/2007/07/26/sun_2048_thread_niagara/) about a possible 2048-core machine. 2048-1 crosscalls per |exec()| won't be fun... ;-( > As an example, to replace most instances of isaexec, we could create > /usr/bin/isaexec > as a mount point, and then during boot mount /usr/bin/i86 or > /usr/bin/amd64 on > /usr/bin/isaexec as a loopback mount. We also change the isaexec > hardlinks in /usr/bin to > be symbolic links pointing to /usr/bin/isaexec/{cmdname}.... no more > runtime isaexec > overhead and no fiddling w/ user paths. That won't work because you have usually more than two entries in the output of /usr/bin/isalist (which is needed to support specially optimized versions for some CPU types like Niagara1 (which doesn't implement all VIS instructions in hardware (which makes the use of -xarch=sparcv8a AFAIK "tricky")) or SPARC64 (which has extra floating-point instructions not available on other SPARC platforms)). And see CR #6474270 ("isaexec and magical builds" - http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270) for another reason why "isaexec" should remain "dynamically" and not turned into a "static" switch. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From bart.smaalders@sun.com Mon Jun 2 14:04:15 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52L4Fl9027063 for ; Mon, 2 Jun 2008 14:04:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m52L4F74029373; Mon, 2 Jun 2008 14:04:15 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00611T72Z300@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 14:04:14 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00KNVT718OE0@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 14:04:13 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m52L4Dcb021651; Mon, 02 Jun 2008 21:04:13 +0000 (GMT) Date: Mon, 02 Jun 2008 14:04:12 -0700 From: Bart Smaalders Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <48445B37.C007CCFE@nrubsig.org> To: Roland Mainz Cc: "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <4844604C.8070903@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> User-Agent: Thunderbird 2.0.0.12 (X11/20080310) Status: RO Content-Length: 1808 Roland Mainz wrote: > Right now "isaexec" isn't that bad. However the extra |exec()| becomes > an issue in two scenarios: > 1. Tiny application with very small runtime (e.g. GNU "echo") > 2. Machine with many CPUs - |exec()| must tear down the address space > and makes crosscalls to all other CPUs... which will be a problem for > the 256CPU Niagara2+ machine... and even more a problem when I read > TheRegister.co.uk's article > (http://www.theregister.co.uk/2007/07/26/sun_2048_thread_niagara/) about > a possible 2048-core machine. 2048-1 crosscalls per |exec()| won't be > fun... ;-( Cross calls limited to the set of CPUs the process has run on so isaexec isn't likely to cause a cross call storm unless there are some pathological context switching problems :-). > That won't work because you have usually more than two entries in the > output of /usr/bin/isalist (which is needed to support specially > optimized versions for some CPU types like Niagara1 (which doesn't > implement all VIS instructions in hardware (which makes the use of > -xarch=sparcv8a AFAIK "tricky")) or SPARC64 (which has extra > floating-point instructions not available on other SPARC platforms)). Who uses this w/ isaexec today? As far as I can tell on sun4v systems, we use sparcv7 and sparcv9, which would readily be served by the proposed mechanism. > And see CR #6474270 ("isaexec and magical builds" - > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270) for > another reason why "isaexec" should remain "dynamically" and not turned > into a "static" switch. They can always invoke the version they want directly. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From jek3@sun.com Mon Jun 2 14:30:06 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52LU52n027690 for ; Mon, 2 Jun 2008 14:30:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m52LTxBX011022; Tue, 3 Jun 2008 05:30:03 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0051TUE0JF00@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 15:30:00 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U00MOSUE0TF40@brm-avmta-1.central.sun.com>; Mon, 02 Jun 2008 15:30:00 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m52LTvhm130643; Mon, 02 Jun 2008 14:29:57 -0700 (PDT) Date: Mon, 02 Jun 2008 11:32:18 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48440DDE.2050403@sun.com> To: Alan Coopersmith Cc: John Plocher , John Plocher , PSARC-ext@sun.com Message-id: <484466E2.60905@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> <48440DDE.2050403@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1612 Alan Coopersmith wrote: > Joseph Kowalski wrote: > >> Speaking of how a "volunteer open *source* community works", >> this is a proposal about how a *binary* distribution should be constructed. >> This is Sun's decision or a decision about a future OpenSolaris >> reference distribution. Tell me again how a volunteer makes this >> distribution configuration decision. >> > > By participating in the OpenSolaris project, which now includes the > building of the OpenSolaris binary distributions. The OpenSolaris > world has changed from the days when distros were all someone else's > problem. Should Sun wish to change this in the future Solaris.next > fork off the OpenSolaris distro, they can - that choice is truly Sun's > to make - but the OpenSolaris 2008.05 and successor distros are being > built with the community, and thus volunteers can make changes like this. > We seem to be in a transition phase. The exact positioning of 2008.05 is still unclear, but probably it will be close to what you seem to believe. AT THE EXACT TIME as this case was submitted, the status of Nevada has been somewhat clarified. So, just maybe what you assert may be true, but the race to these conclusions may just be a little quick. In either case, even if the decision isn't Sun's, its also not just Roland's. Something like this needs to be decided by some community process or body. Sure hope we have something like that. If not, its a sure recipe for disaster. Roland,... several times you referred to a discussion which I assume was on some OpenSolaris discussion alias. Which one? - jek3 From roland.mainz@nrubsig.org Mon Jun 2 14:30:52 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52LUqv0027723 for ; Mon, 2 Jun 2008 14:30:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m52LUohZ027656; Mon, 2 Jun 2008 15:30:51 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U00801UFE4P00@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 14:30:50 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U0074PUFEBZ10@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 14:30:50 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m52LOCk3028551; Mon, 02 Jun 2008 21:30:49 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay44i.sun.com with ESMTP id BT-MMP-193167; Mon, 02 Jun 2008 21:30:49 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-9907716; Mon, 02 Jun 2008 21:30:49 +0000 (Z) Received: from mail-in-14.arcor-online.net ([151.189.21.54] [151.189.21.54]) by relay4i.sun.com with ESMTP id BT-MMP-7515419; Mon, 02 Jun 2008 21:29:49 +0000 (Z) Received: from mail-in-01-z2.arcor-online.net (mail-in-01-z2.arcor-online.net [151.189.8.13]) by mail-in-14.arcor-online.net (Postfix) with ESMTP id B1FE218783D; Mon, 02 Jun 2008 23:29:47 +0200 (CEST) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id A01232BF77E; Mon, 02 Jun 2008 23:29:47 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-021-216.pools.arcor-ip.net [84.59.21.216]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 137411BF4E3; Mon, 02 Jun 2008 23:29:46 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m52LTihQ000758; Mon, 02 Jun 2008 23:29:45 +0200 (CEST) Date: Mon, 02 Jun 2008 23:29:44 +0200 From: Roland Mainz Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351] Sender: gisburn@jupiterb48.nrubsig.org To: John Plocher Cc: PSARC-ext@sun.com Message-id: <48446648.24DAEE63@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/7325/Mon Jun 2 15:45:22 2008 on mail-in-04.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.130sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4844391E.1070504@Sun.Com> Status: RO Content-Length: 6906 John Plocher wrote: [snip] > [I'm attaching Richard's original mail since it was only sent to > opensolaris-arc and probably didn't get into the case mail log] > > Richard L. Hamilton wrote: > > I can think of three main categories of capacity limits on 32-bit that might > > be higher on 64-bit: > > * file size max of 2GB > > * register size and usage > > * available address space, and therefore amount that can be mmap()'d at once > > (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) > > > > AFAIK, only where the address space is an issue is 64-bit all that beneficial > > on SPARC. > > ... > > The file size limit can be lifted on 32-bit with large file support (lfcompile(5)). > > The register usage can be altered in an often helpful way by compiling with > > -xarch=v8plus. Even the stdio problem could be circumvented (using AT&T > > SFIO in place of libc stdio), although that may be an architectural no-no for > > now. > > Roland: Could you respond to Richards comments - it may be that by using > large file support you could get the behavior you want - on both x86 and > SPARC. Largefile support wasn't the goal since 32bit applications in Solaris may have largefile support, too. Mainly the ideas/goals were: -- snip -- - No problem with dates >= 2030 (64bit |time_t|) - High-resolution timestamps by default - Stack would be non-executable by default - ARG_MAX would be larger (twice the size), therefore allowing applications to deal with much more data (note this extra memory is mapped via |mmap()|-like calls and only reserves the size, not actually allocate it (reserved address space != real memory usage)). - "bash" supports arrays and it would be nice that we don't limit the array content to 2GB -- snip -- And just to log it here: The long-term goal is to make both OS/Net and SFWNV "64bit clean", e.g. that we can support hardware which only supports a 64bit mode and no 32bit support (for at least one Solaris port we know that the porters were _forced_ to invent artificial 32bit support to work aound the problem that OS/Net is not 64bit clean (which is IMO an unimaginable abdomination (IMO this comes right after putting kittens into the microwave))). I only wanted to start the journey through the code and picked "GNU coreutils" and "bash" as easy targets to begin this long-term work (but it turned-out that this issue has poisoned teeth, claws, salvia, breathes fire and has 32bit-style heads which only accept 64bit proposals as diet). [snip] > With a 64-bit system, you shouldn't be stuck with a 32-bit limit just > because someone might have a 32 bit system that behaves differently. > Isn't that why we developed 64 bit systems in the first place? Isn't > that why we are doing the OpenSolaris thing - to find and fix these kinds > of problems? Another issue is that OS/Net and SFWNV aren't 64bit clean which prevent Solaris from being ported to 64bit-only hardware. The problem is _known_ since the first 64bit support was added for Solaris 7 and I _finally_ want to start a small project to crawl over the sources and kill the problem. And IMO the _obvious_ solution to prevent this issue in the future is to make the matching binaries 64bit by default if the kernel is 64bit-only. [snip] > Last I heard, unless there was some benefit to be gained, 64-bit was usually > _slower_ on SPARC than 32-bit (unlike x86, where all the extra registers > are a big help), due to larger address constants meaning more data to fetch > (and less effective use of cache?), etc. It would be the pointer size... however the amount of data shuffeled around for pointers depends on how the application works internally. And in the case of "GNU coreutils" and "bash" IMO doesn't matter since a) the difference between 32bit and 64bit is _barely_ measureable and b) AFAIK noone cared about performance of these tools in the past (otherwise such a person would've found a very obvious issue with the build flags already (and it seems I'm the first one who really ran benchmarks and tries to fix the problem)) > I can think of three main categories of capacity limits on 32-bit that might > be higher on 64-bit: > * file size max of 2GB > * register size and usage > * available address space, and therefore amount that can be mmap()'d at once > (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.) > > AFAIK, only where the address space is an issue is 64-bit all that beneficial > on SPARC. Erm... that's not correct. The ideas where more like this: -- snip -- - No problem with dates >= 2030 (64bit |time_t|) - High-resolution timestamps by default - Stack would be non-executable by default - ARG_MAX would be larger (twice the size), therefore allowing applications to deal with much more data (note this extra memory is mapped via |mmap()|-like calls and only reserves the size, not actually allocate it (reserved address space != real memory usage)). - "bash" supports arrays and it would be nice that we don't limit the array content to 2GB -- snip -- > The file size limit can be lifted on 32-bit with large file support (lfcompile(5)). > The register usage can be altered in an often helpful way by compiling with > -xarch=v8plus. Erm... small correction: -xarch=v8plus cannot safely be mixed with other sparcv7 code in all cases (nor was the width of registers an issue here). > Even the stdio problem could be circumvented (using AT&T > SFIO in place of libc stdio), although that may be an architectural no-no for > now. Why ? Technically I would strongly prefer to use an ARC contract for |libast::stdio| than trying to deal with |libc::stdio| if I hit such limits (the reason is simply performance - the libast version of stdio outperforms libc's stdio in all benchmarks and scales a lot better for large amounts of FDs). > A cursory glance at the programs in question suggests that not all of them > would have any use for a larger address space; those could probably receive > all the benefits (and not the possible performance drawbacks) of 64-bitness > by just being built with large file support and compiled as v8plus. Umpf... "GNU coreutils" and "bash" are only two packages which cannot be split into smaller pieces without pain. And "sparcv8plus" won't help a lot since it#s still 32bit and has no access to a larger addressspace, 64bit timestamps or other items listed above. > Where that would be sufficient to reach maximum capacity limits, I think > performance testing of large file+v8plus versus v9 (64-bit) should be considered, > to avoid regression. See my other email about performance regressions. Compared to the current 32bit versions we will likely improve the situation by fixing the build flags. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From jek3@sun.com Mon Jun 2 14:36:06 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52La5ot027837 for ; Mon, 2 Jun 2008 14:36:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m52La0wa006405; Mon, 2 Jun 2008 22:36:03 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0080LUO1DK00@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 14:36:01 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U007EUUO1C310@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 14:36:01 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m52La0Qj131779; Mon, 02 Jun 2008 14:36:00 -0700 (PDT) Date: Mon, 02 Jun 2008 11:38:21 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <484428A0.6010108@Sun.COM> To: Bart Smaalders Cc: Darren J Moffat , John Plocher , PSARC-ext@sun.com Message-id: <4844684D.4040703@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 356 Bart Smaalders wrote: > I assume that the proposal here is to deliver 64 bit versions of these > commands > on sparc, and both 32 and 64 bit versions on x86. I never saw this in the proposal. I believe is only said that the 64 bit versions would be delivered on SPARC. No significant mention of x86, leaving the status quo to be only 32 bits. - jek3 From jek3@sun.com Mon Jun 2 14:39:41 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m52LdeW8027943 for ; Mon, 2 Jun 2008 14:39:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m52LdNkq014035; Tue, 3 Jun 2008 05:39:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1U0080BUTWIO00@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 14:39:32 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1U007P7UTWC810@nwk-avmta-2.sfbay.sun.com>; Mon, 02 Jun 2008 14:39:32 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m52LdVOV132583; Mon, 02 Jun 2008 14:39:31 -0700 (PDT) Date: Mon, 02 Jun 2008 11:41:51 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48442EA9.7020502@sun.com> To: "Garrett D'Amore" Cc: Bart Smaalders , Darren J Moffat , John Plocher , PSARC-ext@sun.com Message-id: <4844691F.9000203@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 619 Garrett D'Amore wrote: > My personal preference, for now, would be to deliver *both* 32- and > 64-bit versions of the applications for both SPARC and x86, but > deliver the 64-bit versions in a separate path (/usr/bin/sparcv9 and > /usr/bin/amd64 or somesuch), so that end users can just adjust their > $PATH appropriately if they know they need or want 64-bit capable > programs (I think for the vast majority of users, this will not be > necessary.) Or, we could do what all linux distributors do, and provide completely separate 32 and 64 bit products. This could be a lot of pain, for little gain. - jek3 From Darren.Moffat@sun.com Tue Jun 3 03:33:06 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53AX6td019753 for ; Tue, 3 Jun 2008 03:33:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m53AX2KB009718 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 3 Jun 2008 04:33:05 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1V0081FUN5M400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 03:33:05 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1V00MZ4UN46RC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 03:33:05 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m53AX3UQ004180 for ; Tue, 03 Jun 2008 10:33:03 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1V00H01TT40100@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 11:33:03 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1V001X2UMIXD70@fe-emea-10.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 11:32:43 +0100 (BST) Date: Tue, 03 Jun 2008 11:32:42 +0100 From: Darren J Moffat Subject: Re: Full case ? / was: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351Self Review] In-reply-to: <18500.21884.917957.881148@gargle.gargle.HOWL> Sender: Darren.Moffat@sun.com To: PSARC-EXT@sun.com, Roland Mainz Message-id: <48451DCA.6010100@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48444684.4010209@sun.com> <20080602192524.GD2735@Sun.COM> <48444CBE.89BB05C0@nrubsig.org> <20080602194252.GG2735@Sun.COM> <48445219.3030704@Sun.COM> <20080602200721.GJ2735@Sun.COM> <18500.21884.917957.881148@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 270 To make it clear on the record since it obviously wasn't to many people given the slight incorrect language I used. I do not believe this case qualified for self review or automatic approval. Please submit a proposal and start a fast-track timer. -- Darren J Moffat From Joerg.Schilling@fokus.fraunhofer.de Tue Jun 3 03:47:32 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53AlVBw019867 for ; Tue, 3 Jun 2008 03:47:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m53AlObI026192; Tue, 3 Jun 2008 11:47:28 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1V00205VB28T00@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 03:47:26 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1V00LJ1VB1N740@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 03:47:25 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m53AlPGn024412; Tue, 03 Jun 2008 10:47:25 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay41i.sun.com with ESMTP id BT-MMP-211305; Tue, 03 Jun 2008 10:47:25 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-10844294; Tue, 03 Jun 2008 10:47:24 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay4i.sun.com with ESMTP id BT-MMP-8203403; Tue, 03 Jun 2008 10:47:24 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw13] (8.14.2+/8.14.2) with ESMTP id m53AdNLJ028197; Tue, 03 Jun 2008 12:39:23 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m53AdMMf028176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 03 Jun 2008 12:39:23 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m53AdMTW017640; Tue, 03 Jun 2008 12:39:22 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 03 Jun 2008 12:39:22 +0200 Date: Tue, 03 Jun 2008 12:39:21 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48405B59.6050306@sun.com> To: jek3@sun.com, Alan.Coopersmith@sun.com Cc: PSARC-ext@sun.com, plocher@sac.sfbay.sun.com, John.Plocher@sun.com Message-id: <48451f59.qNcy3ILpN+RJJ9Py%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.087sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <48404BE2.4060207@Sun.Com> <4840547E.70202@sun.com> <48405B59.6050306@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 03 Jun 2008 10:39:22.0483 (UTC) FILETIME=[15E69C30:01C8C566] Status: RO Content-Length: 1207 Alan Coopersmith wrote: > Joseph Kowalski wrote: > > I don't see why /usr/gnu/bin/awk should get preference over /usr/bin/awk > > just because its in gnucore. > > How about because it's already known to be 64-bit clean since the GNU > utilities run on platforms that are 64-bit only, while the Solaris > versions may or may not be ready to go? It is well known that most Solaris utilities are not 64 bit clean (see e.g. sccs tools and execl(2) calling bugs that I fixed a year ago and reported...). A short check of some other commands finds: modload, modunload, power*, zlogin [this is really bad!!!!], dc, bdiff, init, cachefs*, volcopy, fsdb, edquota, newgrp, eject, yp*, lpadmin, libssh*, crypt, ... let me stop here, there are just too many. I am not sure whether the GNU tools are 64 bit clean. Note that the DEC Alpha port of Linux used a ILP64 compile environment. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Tue Jun 3 06:02:58 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53D2v0D022572 for ; Tue, 3 Jun 2008 06:02:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m53D2dmM027071; Tue, 3 Jun 2008 21:02:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W001031KQQQ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Jun 2008 06:02:50 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00B5U1KP8E70@nwk-avmta-1.sfbay.Sun.COM>; Tue, 03 Jun 2008 06:02:49 -0700 (PDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m53D2mXH022688; Tue, 03 Jun 2008 13:02:48 +0000 (GMT) Received: from mms25es.mms.us.syntegra.com ([150.143.232.90] [150.143.232.90]) by relay23i.sun.com with ESMTP id BT-MMP-384127; Tue, 03 Jun 2008 13:02:48 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms25es.mms.us.syntegra.com with ESMTP id BT-MMP-12023178; Tue, 03 Jun 2008 13:02:48 +0000 (Z) Received: from mailgwb1.fraunhofer.de ([153.96.87.18] [153.96.87.18]) by relay22i.sun.com with ESMTP id BT-MMP-14832364; Tue, 03 Jun 2008 13:02:47 +0000 (Z) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id m53Cvf88025203; Tue, 03 Jun 2008 14:57:41 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m53CvedU025141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 03 Jun 2008 14:57:40 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m53CvdmO025955; Tue, 03 Jun 2008 14:57:39 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 03 Jun 2008 14:57:39 +0200 Date: Tue, 03 Jun 2008 14:57:39 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: To: james.d.carlson@sun.com, iszczesniak@gmail.com Cc: rlhamil@smart.net, PSARC-ext@sun.com, Alan.Coopersmith@sun.com Message-id: <48453fc3.2WGjDK5NGVOwDXJB%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.322sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> <18500.16414.347283.124172@gargle.gargle.HOWL> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 03 Jun 2008 12:57:39.0792 (UTC) FILETIME=[677B7D00:01C8C579] Status: RO Content-Length: 807 "I. Szczesniak" wrote: > > It's also lifted if you call enable_extended_FILE_stdio(3C), use the > > extendedFILE.so.1 preload, or 'F' is used as the last character in the > > fopen(3C) mode string. > > FYI, enable_extended_FILE_stdio(3C) is incompatible to many > applications, including coreutil. Using a FD > 256 crashes such > applications. I would expect it to be incompatible to any precompiled code that asumes that fileno() is a macro bscause it has been at compile time. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Tue Jun 3 06:04:07 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53D463R022586 for ; Tue, 3 Jun 2008 06:04:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m53D3xx0027637; Tue, 3 Jun 2008 21:04:02 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W00D031MPGW00@brm-avmta-1.central.sun.com>; Tue, 03 Jun 2008 07:04:01 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00AMK1MN8DE0@brm-avmta-1.central.sun.com>; Tue, 03 Jun 2008 07:03:59 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m53D2uCx008818; Tue, 03 Jun 2008 13:03:59 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-261024; Tue, 03 Jun 2008 13:03:58 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-340910; Tue, 03 Jun 2008 13:03:58 +0000 (Z) Received: from mailgwb1.fraunhofer.de ([153.96.87.18] [153.96.87.18]) by relay1ib.sun.com with ESMTP id BT-MMP-3592062; Tue, 03 Jun 2008 13:03:58 +0000 (Z) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id m53CruQf016428; Tue, 03 Jun 2008 14:53:56 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m53CruYh016393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 03 Jun 2008 14:53:56 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m53Crtno025776; Tue, 03 Jun 2008 14:53:55 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 03 Jun 2008 14:53:55 +0200 Date: Tue, 03 Jun 2008 14:53:55 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48443BC3.1010802@Sun.COM> To: gdamore@sun.com, bart.smaalders@sun.com Cc: PSARC-ext@sun.com, plocher@sac.sfbay.sun.com, jek3@sun.com Message-id: <48453ee3.S7BrKJuzb1p0rUPU%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.085sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 03 Jun 2008 12:53:55.0567 (UTC) FILETIME=[E1D577F0:01C8C578] Status: RO Content-Length: 845 Bart Smaalders wrote: > x86 will for now need to deliver both 32 and 64 bit binaries. If you're > worried > about the performance issues involved w/ isaexec, then let's design > something If we start talking about isaexec, we should also talk about pfexec. I would like to see the code moved into the kernel. Other possible ways of getting rid of a userspace implementation for the pfexec features would be to implement something like capabilities that may replace suid(0) to setppriv(cap-list from filesystem). Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Tue Jun 3 06:07:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53D7t9o022602 for ; Tue, 3 Jun 2008 06:07:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m53D7kkg023562; Tue, 3 Jun 2008 14:07:51 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W0080P1T1DB00@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 06:07:49 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00LX21T0NAB0@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 06:07:48 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m53D7lUB013058; Tue, 03 Jun 2008 13:07:47 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-261248; Tue, 03 Jun 2008 13:07:47 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-20801970; Tue, 03 Jun 2008 13:07:47 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay1i.sun.com with ESMTP id BT-MMP-3787279; Tue, 03 Jun 2008 13:07:47 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw12] (8.14.2+/8.14.2) with ESMTP id m53D3e80019359; Tue, 03 Jun 2008 15:03:40 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m53D3bPJ019324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 03 Jun 2008 15:03:40 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m53D3bvD026359; Tue, 03 Jun 2008 15:03:37 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 03 Jun 2008 15:03:37 +0200 Date: Tue, 03 Jun 2008 15:03:37 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: <18500.18219.433958.307965@gargle.gargle.HOWL> To: james.d.carlson@sun.com, iszczesniak@gmail.com Cc: rlhamil@smart.net, PSARC-ext@sun.com, Alan.Coopersmith@sun.com Message-id: <48454129.3NbNEs8UyY1UE9U3%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.126sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> <18500.16414.347283.124172@gargle.gargle.HOWL> <18500.18219.433958.307965@gargle.gargle.HOWL> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 03 Jun 2008 13:03:37.0754 (UTC) FILETIME=[3CD827A0:01C8C57A] Status: RO Content-Length: 892 James Carlson wrote: > > FYI, enable_extended_FILE_stdio(3C) is incompatible to many > > applications, including coreutil. Using a FD > 256 crashes such > > applications. > > "Coreutil"? As in GNU coreutils? > > If there's a problem here, and it's not just broken code in the > application, then filing bugs would help. I searched for, but did not > find, any references to this problem either at any external site or in > the bug databases. If you pass a fp with a fd > 255 to code that has been compiled before fileno() become a function, this code may crash. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Tue Jun 3 06:10:15 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53DAEM0022619 for ; Tue, 3 Jun 2008 06:10:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m53DA49g024583; Tue, 3 Jun 2008 14:10:11 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W0080L1WYGA00@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 06:10:10 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00LZP1WYNGB0@nwk-avmta-2.sfbay.sun.com>; Tue, 03 Jun 2008 06:10:10 -0700 (PDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m53D6sZv028392; Tue, 03 Jun 2008 13:10:10 +0000 (GMT) Received: from mms22es.mms.us.syntegra.com ([150.143.232.30] [150.143.232.30]) by relay21i.sun.com with ESMTP id BT-MMP-1258804; Tue, 03 Jun 2008 13:10:09 +0000 (Z) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54]) by mms22es.mms.us.syntegra.com with ESMTP id BT-MMP-12037770; Tue, 03 Jun 2008 13:10:09 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay23i.sun.com with ESMTP id BT-MMP-14892928; Tue, 03 Jun 2008 13:10:09 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw21] (8.14.2+/8.14.2) with ESMTP id m53D27aM023696; Tue, 03 Jun 2008 15:02:07 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m53D27Uo023690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 03 Jun 2008 15:02:07 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m53D26KD026254; Tue, 03 Jun 2008 15:02:06 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 03 Jun 2008 15:02:06 +0200 Date: Tue, 03 Jun 2008 15:02:06 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48444684.4010209@sun.com> To: gdamore@sun.com, Bart.Smaalders@sun.com Cc: PSARC-ext@sun.com, plocher@sac.sfbay.sun.com, jek3@sun.com Message-id: <484540ce.CUwd7+MkQRGSNs6W%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.153sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48444684.4010209@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 03 Jun 2008 13:02:06.0845 (UTC) FILETIME=[06A88AD0:01C8C57A] Status: RO Content-Length: 753 "Garrett D'Amore" wrote: > (As far as "something better", I think I prefer something along the > lines of how AFS handles it, where $VARIABLE could be used within a > symbolic link -- the kernel expands the variable when following the > symlink. But we shouldn't try to design the solution here, I think.) This idea (kernel evaluated symlink cmponents like /usr/$ARCH/bin/) was even in use 20+ years ago on Apollo Domain OS ;-) Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From darrenm@opensolaris.org Tue Jun 3 07:41:43 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53EfgQq024673 for ; Tue, 3 Jun 2008 07:41:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m53Efb6N005336 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 3 Jun 2008 22:41:41 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W00B1B65GN100@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 07:41:40 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W00ALB6598Z40@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 07:41:39 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m53EfXoC015186 for ; Tue, 03 Jun 2008 14:41:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1W00H01315P800@fe-emea-10.sun.com> (original mail from darrenm@opensolaris.org) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 15:41:33 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1W009Y664SQ680@fe-emea-10.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 03 Jun 2008 15:41:18 +0100 (BST) Date: Tue, 03 Jun 2008 15:41:16 +0100 From: Darren J Moffat Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit PSARC 2008/351 In-reply-to: <9405164.1212502435336.JavaMail.Twebapp@oss-app2> Sender: Darren.Moffat@sun.com To: "Richard L. Hamilton" Cc: PSARC-EXT@sun.com Message-id: <4845580C.30101@opensolaris.org> Organization: OpenSolaris MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <9405164.1212502435336.JavaMail.Twebapp@oss-app2> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 514 Richard L. Hamilton wrote: >> - Stack would be non-executable by default > An advantage, certainly, although if someone is paranoid (and has no > self-modifying code that would choke on it), this can be done for 32-bit with > an /etc/system setting. The ON consolidation, and some others, already ensure that 32 bit programs are built with a non executable stack. It is the default on ON and can easily be done in other consolidations by using the linker mapfile /usr/lib/ld/map.noexstk. -- Darren J Moffat From scott.rotondo@sun.com Tue Jun 3 12:08:14 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m53J8ECn005805 for ; Tue, 3 Jun 2008 12:08:14 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m53J8Ee2010010 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 3 Jun 2008 12:08:14 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1W00F01IHQZP00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Jun 2008 13:08:14 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1W008ZJIHP9L90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 03 Jun 2008 13:08:13 -0600 (MDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m53J8DRM216456; Tue, 03 Jun 2008 12:08:13 -0700 (PDT) Date: Tue, 03 Jun 2008 12:08:13 -0700 From: Scott Rotondo Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351 Self Review] In-reply-to: <48453ee3.S7BrKJuzb1p0rUPU%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg Schilling Cc: PSARC-ext@sun.com Message-id: <4845969D.60506@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48453ee3.S7BrKJuzb1p0rUPU%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 418 Joerg Schilling wrote: > If we start talking about isaexec, we should also talk about pfexec. I would > like to see the code moved into the kernel. Other possible ways of getting rid > of a userspace implementation for the pfexec features would be to implement > something like capabilities that may replace > suid(0) to setppriv(cap-list from filesystem). See http://www.opensolaris.org/os/project/fgap/ Scott From roland.mainz@nrubsig.org Mon Jun 9 00:23:03 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m597N2Mj026583 for ; Mon, 9 Jun 2008 00:23:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m597Msfx003449; Mon, 9 Jun 2008 08:22:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2600L05PU92500@nwk-avmta-2.sfbay.sun.com>; Mon, 09 Jun 2008 00:22:57 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2600GR2PU9PDC0@nwk-avmta-2.sfbay.sun.com>; Mon, 09 Jun 2008 00:22:57 -0700 (PDT) Received: from relay16i.sun.com (ip126.net129179-4.block1.us.syntegra.com [129.179.4.126]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m597MusD001969; Mon, 09 Jun 2008 07:22:56 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay16i.sun.com with ESMTP id BT-MMP-489979; Mon, 09 Jun 2008 07:22:56 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-31121640; Mon, 09 Jun 2008 07:22:56 +0000 (Z) Received: from mail-in-08.arcor-online.net ([151.189.21.48] [151.189.21.48]) by relay1i.sun.com with ESMTP id BT-MMP-7008178; Mon, 09 Jun 2008 07:22:55 +0000 (Z) Received: from mail-in-16-z2.arcor-online.net (mail-in-16-z2.arcor-online.net [151.189.8.33]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id 7E0FE27AC8C; Mon, 09 Jun 2008 09:22:54 +0200 (CEST) Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) by mail-in-16-z2.arcor-online.net (Postfix) with ESMTP id 59AD4254886; Mon, 09 Jun 2008 09:22:54 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-088-068-030-024.pools.arcor-ip.net [88.68.30.24]) by mail-in-10.arcor-online.net (Postfix) with ESMTP id 759D32351A7; Mon, 09 Jun 2008 09:22:53 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m597Moum001643; Mon, 09 Jun 2008 09:22:51 +0200 (CEST) Date: Mon, 09 Jun 2008 09:22:50 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351SelfReview] Sender: gisburn@jupiterb48.nrubsig.org To: Bart Smaalders Cc: "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <484CDA4A.A6F8F67C@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.92.1/7407/Mon Jun 9 04:21:00 2008 on mail-in-10.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.110sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> Status: RO Content-Length: 824 Bart Smaalders wrote: > Roland Mainz wrote: > > Right now "isaexec" isn't that bad. However the extra |exec()| becomes > > an issue in two scenarios: > > 1. Tiny application with very small runtime (e.g. GNU "echo") > > 2. Machine with many CPUs - |exec()| must tear down the address space > > and makes crosscalls to all other CPUs... which will be a problem for > > the 256CPU Niagara2+ machine... and even more a problem when I read > > TheRegister.co.uk's article > > (http://www.theregister.co.uk/2007/07/26/sun_2048_thread_niagara/) about > > a possible 2048-core machine. 2048-1 crosscalls per |exec()| won't be > > fun... ;-( > > Cross calls limited to the set of CPUs the process has run on so isaexec > isn't likely to cause a cross call storm unless there are some pathological > context switching problems :-). From what I know there were several high-priority escalations on Status: RO SF15K/25K machines last year where Bourne/bash scripts were causing system-wide performance problems just because they were |fork()|+|exec()|'ing madly (three solutions: Get rid of the shells completely, adjust the script code to avoid unneccesary subshells or use ksh93 (which avoids |fork()|+|exec()| unless it is unavoideable (and newer versions try to use |posix_spawn()|))) ... and from my own experience a tight |exec()|-loop can nail large machines (e.g. M8000) against the next available wall. It sounds that the "pathological case" happens very often (the problem gets even worse when the application uses largepages (but don't ask me _why_ this happens...)). > > That won't work because you have usually more than two entries in the > > output of /usr/bin/isalist (which is needed to support specially > > optimized versions for some CPU types like Niagara1 (which doesn't > > implement all VIS instructions in hardware (which makes the use of > > -xarch=sparcv8a AFAIK "tricky")) or SPARC64 (which has extra > > floating-point instructions not available on other SPARC platforms)). > > Who uses this w/ isaexec today? As far as I can tell on sun4v systems, > we use sparcv7 and sparcv9, which would readily be served by the > proposed mechanism. I don't know whether we use it this way right now. However we _know_ that it would make sense to ship SSE3 (or which SSE*-thing had the fast strcopy/compare operations) binaries if SSE3 is supported in hardware. The same applies for VIS vs. non-VIS in cases like "mplayer"&co. > > And see CR #6474270 ("isaexec and magical builds" - > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6474270) for > > another reason why "isaexec" should remain "dynamically" and not turned > > into a "static" switch. > > They can always invoke the version they want directly. Please read the RFE again - it is needed for development of applications which should support both 32bit+64bit systems (and just trying to "fix" the matching build systems is hopeless - it's like trying to boil the oceans. You can't fix each instance of autoconf&co.) and to handle cases where only 32bit applications are suiteable for a task (e.g. if a plugin is needed where the required libraries are only available as 32bit binaries). Right now the only "workaround" is to become the "root" user and move the matching binaries around. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From gdamore@sun.com Mon Jun 9 09:23:33 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m59GNXSa007385 for ; Mon, 9 Jun 2008 09:23:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m59GNOYA025282 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 9 Jun 2008 09:23:33 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2700F1REV8JU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 09 Jun 2008 09:23:32 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2700793EUYJOA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 09 Jun 2008 09:23:22 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m59GNMlN019774 for ; Mon, 09 Jun 2008 09:23:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2700I01CCUYZ00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 09 Jun 2008 09:23:22 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K270068NEUPSI40@fe-sfbay-10.sun.com>; Mon, 09 Jun 2008 09:23:13 -0700 (PDT) Date: Mon, 09 Jun 2008 09:22:25 -0700 From: "Garrett D'Amore" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351SelfReview] In-reply-to: <484CDA4A.A6F8F67C@nrubsig.org> Sender: Garrett.Damore@sun.com To: Roland Mainz Cc: Bart Smaalders , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <484D58C1.1090108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1754 Roland Mainz wrote: > > > Please read the RFE again - it is needed for development of applications > which should support both 32bit+64bit systems (and just trying to "fix" > the matching build systems is hopeless - it's like trying to boil the > oceans. You can't fix each instance of autoconf&co.) and to handle cases > where only 32bit applications are suiteable for a task (e.g. if a plugin > is needed where the required libraries are only available as 32bit > binaries). Right now the only "workaround" is to become the "root" user > and move the matching binaries around. > I see a problem with this assertion: Either: 1) the application works on 32-bit, and hence doesn't need the 64-bit tools 2) the application does not work on 32-bit and needs 64-bit tools I recognize that there are *some* applications which perhaps can perform better on 64-bits, perhaps supporting larger data sets or somesuch. But the fact that the application's behavior is inconsistent going from 32- to 64- without any obvious way for the end user to realize the cause of the difference gives me a bit of a pause. I still think I'd recommend that the case be pruned back to delivering a /usr/bin/64/bash (or somesuch) which is *available* to consumers, but doesn't make it used by default. Then, developers which *need* it right now at least have a recourse. (Most likely, the most pressing consumers for this already know they need 64-bit support.) Follow up case work can be done to investigate the possibility of use of isaexec() (or hopefully a better mechanism yet to be designed) to pick the best binary for the platform. In other words, I think the project team shouldn't be afraid to tackle this problem by baby steps. -- Garrett From jek3@sun.com Mon Jun 9 11:25:40 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m59IPej8013752 for ; Mon, 9 Jun 2008 11:25:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m59IPd6O000280; Mon, 9 Jun 2008 11:25:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2700707KIROI00@brm-avmta-1.central.sun.com>; Mon, 09 Jun 2008 12:25:39 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K27001GMKIQLC70@brm-avmta-1.central.sun.com>; Mon, 09 Jun 2008 12:25:38 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m59IPb6h360656; Mon, 09 Jun 2008 11:25:37 -0700 (PDT) Date: Mon, 09 Jun 2008 08:28:14 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351SelfReview] In-reply-to: <484CDA4A.A6F8F67C@nrubsig.org> To: Roland Mainz Cc: Bart Smaalders , "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher Message-id: <484D763E.1000404@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 573 I'm sorry. I was supposed to contact you after the last PSARC meeting. There is no serious fast-track specification for this case. If we are unable to proceed with out one. The project team needs to produce one. At a minimum, such a proposal needs a very clear list of the effected utilities and the rationale for the list of effected utilities. This isn't a request for a new justification (that is spread around the mail trail) - just a "specification worthy" statement from the submitter. Again, I should have done this 3 or 4 days ago. I'm sorry. - jek3 From jek3@sun.com Mon Jun 9 11:35:26 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m59IZQ4s014437 for ; Mon, 9 Jun 2008 11:35:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m59IZNk0003281; Mon, 9 Jun 2008 11:35:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2700111KZ1NU00@nwk-avmta-2.sfbay.sun.com>; Mon, 09 Jun 2008 11:35:25 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2700JYRKYZ2080@nwk-avmta-2.sfbay.sun.com>; Mon, 09 Jun 2008 11:35:23 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m59IZND4362750; Mon, 09 Jun 2008 11:35:23 -0700 (PDT) Date: Mon, 09 Jun 2008 08:38:00 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] To: PSARC-ext@sun.com Message-id: <484D7888.1090207@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1100 I'm not sure why this was just sent to Plocher and myself. Respecting this, I removed the sender's name. Its a little bit of more information for the 32/64 bit discussion. > friends, while reading the discussion on $SUBJECT, fwiw there is a more > subtle reason for working on 64 bit usr utilities, namely: > > 6709455 file utilities should be able to manipulate files with wrong timestamp > http://monaco.sfbay/detail.jsf?cr=6709455 > > 6248065 *ls* should be isaexec'ed (64bit on 64bit kernel, 32bit on 32bit kernel) > http://monaco.sfbay/detail.jsf?cr=6248065 > > problems is, in a heterogeneous environment it can happen that files > on the solaris server get created with a timestamp that overflows the 32 bit time_t > and the administrator has no way of getting rid of those files, we've seen this > in particular comming from MACOS / windows clients via samba/nfs The first CR is rather new - possibly created for this discussion. The second CR is 3 years old, but phrased as an RFE. (I'm personally disappointed that this CR/RFE has been sitting there rotting.) Just FYI, - jek3 From roland.mainz@nrubsig.org Tue Jun 10 08:15:32 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AFFWjL023404 for ; Tue, 10 Jun 2008 08:15:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5AFFT5O060459; Tue, 10 Jun 2008 09:15:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900C0H6DUQQ00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jun 2008 08:15:30 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K29008A46DTDDF0@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jun 2008 08:15:29 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5AFFSl2029202; Tue, 10 Jun 2008 15:15:28 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay43i.sun.com with ESMTP id BT-MMP-464187; Tue, 10 Jun 2008 15:15:28 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-24841585; Tue, 10 Jun 2008 15:15:28 +0000 (Z) Received: from mail-in-13.arcor-online.net ([151.189.21.53] [151.189.21.53]) by relay4i.sun.com with ESMTP id BT-MMP-16563142; Tue, 10 Jun 2008 15:15:27 +0000 (Z) Received: from mail-in-17-z2.arcor-online.net (mail-in-17-z2.arcor-online.net [151.189.8.34]) by mail-in-13.arcor-online.net (Postfix) with ESMTP id 823D41E507C; Tue, 10 Jun 2008 17:15:26 +0200 (CEST) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-17-z2.arcor-online.net (Postfix) with ESMTP id 6E4E645C042; Tue, 10 Jun 2008 17:15:26 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-029-194.pools.arcor-ip.net [84.59.29.194]) by mail-in-11.arcor-online.net (Postfix) with ESMTP id 22617249257; Tue, 10 Jun 2008 17:15:23 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m5AFFLpg002920; Tue, 10 Jun 2008 17:15:21 +0200 (CEST) Date: Tue, 10 Jun 2008 17:15:20 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Bart Smaalders , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <484E9A88.7CB5C77E@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.93/7407/Mon Jun 9 04:21:00 2008 on mail-in-11.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.079sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D58C1.1090108@sun.com> Status: RO Content-Length: 2461 Garrett D'Amore wrote: > Roland Mainz wrote: > > Please read the RFE again - it is needed for development of applications > > which should support both 32bit+64bit systems (and just trying to "fix" > > the matching build systems is hopeless - it's like trying to boil the > > oceans. You can't fix each instance of autoconf&co.) and to handle cases > > where only 32bit applications are suiteable for a task (e.g. if a plugin > > is needed where the required libraries are only available as 32bit > > binaries). Right now the only "workaround" is to become the "root" user > > and move the matching binaries around. > > I see a problem with this assertion: > > Either: > > 1) the application works on 32-bit, and hence doesn't need the 64-bit tools > > 2) the application does not work on 32-bit and needs 64-bit tools > > I recognize that there are *some* applications which perhaps can perform > better on 64-bits, perhaps supporting larger data sets or somesuch. But > the fact that the application's behavior is inconsistent going from 32- > to 64- without any obvious way for the end user to realize the cause of > the difference gives me a bit of a pause. > > I still think I'd recommend that the case be pruned back to delivering a > /usr/bin/64/bash (or somesuch) which is *available* to consumers, but > doesn't make it used by default. Then, developers which *need* it right > now at least have a recourse. (Most likely, the most pressing consumers > for this already know they need 64-bit support.) > > Follow up case work can be done to investigate the possibility of use of > isaexec() (or hopefully a better mechanism yet to be designed) to pick > the best binary for the platform. > > In other words, I think the project team shouldn't be afraid to tackle > this problem by baby steps. The trouble is that this increases the workload of a simple "make OS/Net+SFWNV 64bit clean by switching to 64bit binaries on 64bit-only platforms" by a factor of at least _three_ (delivering twice the number of binaries, do the matching testing _and_ implementing packaging changes (and the testing for it)). This is technically ARC'able but no longer implementable for a single contributor (at least not if we intend to crawl over both trees and clean them up). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From gdamore@sun.com Tue Jun 10 08:29:44 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AFTh7F023537 for ; Tue, 10 Jun 2008 08:29:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5AFTe4j013131 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jun 2008 23:29:42 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900F1P71GEM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 09:29:40 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900DVD71EQU10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 09:29:38 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5AFTcD4020045 for ; Tue, 10 Jun 2008 08:29:38 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900M015F8YY00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 08:29:38 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K29009B2712WA60@fe-sfbay-10.sun.com>; Tue, 10 Jun 2008 08:29:27 -0700 (PDT) Date: Tue, 10 Jun 2008 08:28:36 -0700 From: "Garrett D'Amore" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484E9A88.7CB5C77E@nrubsig.org> Sender: Garrett.Damore@sun.com To: Roland Mainz Cc: Bart Smaalders , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <484E9DA4.40706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D58C1.1090108@sun.com> <484E9A88.7CB5C77E@nrubsig.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 3098 Roland Mainz wrote: > Garrett D'Amore wrote: > >> Roland Mainz wrote: >> >>> Please read the RFE again - it is needed for development of applications >>> which should support both 32bit+64bit systems (and just trying to "fix" >>> the matching build systems is hopeless - it's like trying to boil the >>> oceans. You can't fix each instance of autoconf&co.) and to handle cases >>> where only 32bit applications are suiteable for a task (e.g. if a plugin >>> is needed where the required libraries are only available as 32bit >>> binaries). Right now the only "workaround" is to become the "root" user >>> and move the matching binaries around. >>> >> I see a problem with this assertion: >> >> Either: >> >> 1) the application works on 32-bit, and hence doesn't need the 64-bit tools >> >> 2) the application does not work on 32-bit and needs 64-bit tools >> >> I recognize that there are *some* applications which perhaps can perform >> better on 64-bits, perhaps supporting larger data sets or somesuch. But >> the fact that the application's behavior is inconsistent going from 32- >> to 64- without any obvious way for the end user to realize the cause of >> the difference gives me a bit of a pause. >> >> I still think I'd recommend that the case be pruned back to delivering a >> /usr/bin/64/bash (or somesuch) which is *available* to consumers, but >> doesn't make it used by default. Then, developers which *need* it right >> now at least have a recourse. (Most likely, the most pressing consumers >> for this already know they need 64-bit support.) >> >> Follow up case work can be done to investigate the possibility of use of >> isaexec() (or hopefully a better mechanism yet to be designed) to pick >> the best binary for the platform. >> >> In other words, I think the project team shouldn't be afraid to tackle >> this problem by baby steps. >> > > The trouble is that this increases the workload of a simple "make > OS/Net+SFWNV 64bit clean by switching to 64bit binaries on 64bit-only > platforms" by a factor of at least _three_ (delivering twice the number > of binaries, do the matching testing _and_ implementing packaging > changes (and the testing for it)). This is technically ARC'able but no > longer implementable for a single contributor (at least not if we intend > to crawl over both trees and clean them up). > The paragraph above describes a goal that goes far beyond the original stated intent of this case, and would need to be backed by a full case. Completely inappropriate for a fast track. If you want to switch to 64-bit binaries across the board on 64-bit platforms (or even have that as a stated goal), then the intent needs to undergo a separate full review. Please clarify. -- Garrett Btw, if we are only talking about one or two utilities, then the binary additions and packaging changes are fairly modest. Probably doable in less than hour. The *testing* changes are not that large. I still think baby steps here are more appropriate than boiling the worlds oceans at once. > ---- > > Bye, > Roland > > From Darren.Moffat@sun.com Tue Jun 10 09:12:25 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AGCPij025971 for ; Tue, 10 Jun 2008 09:12:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5AGCKLw012402 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jun 2008 09:12:24 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900E2990NGR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 09:12:23 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900DHK90J5A30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 09:12:20 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5AGCJ3p028510 for ; Tue, 10 Jun 2008 16:12:19 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900D018D2CQ00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 17:12:19 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K290002390HWV30@fe-emea-09.sun.com>; Tue, 10 Jun 2008 17:12:18 +0100 (BST) Date: Tue, 10 Jun 2008 17:12:17 +0100 From: Darren J Moffat Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484E9DA4.40706@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Roland Mainz , PSARC-ext@sun.com, Bart Smaalders , Joseph Kowalski , John Plocher Message-id: <484EA7E1.30001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D58C1.1090108@sun.com> <484E9A88.7CB5C77E@nrubsig.org> <484E9DA4.40706@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 201 Why do we still not have a spec for this case ? I and others have asked for it. Why is this case still marked as closed approved automatic, when it should be waiting need spec ? -- Darren J Moffat From Darren.Moffat@sun.com Tue Jun 10 09:16:48 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AGGler026185 for ; Tue, 10 Jun 2008 09:16:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5AGGY4s024733 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jun 2008 17:16:46 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900E0F97VM400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 09:16:43 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900DYS97U5420@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 09:16:43 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5AGGgIr028915 for ; Tue, 10 Jun 2008 16:16:42 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K29007017LT4800@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 17:16:42 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K290008197JWV30@fe-emea-09.sun.com>; Tue, 10 Jun 2008 17:16:31 +0100 (BST) Date: Tue, 10 Jun 2008 17:16:30 +0100 From: Darren J Moffat Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484E9A88.7CB5C77E@nrubsig.org> Sender: Darren.Moffat@sun.com To: Roland Mainz Cc: "Garrett D'Amore" , Bart Smaalders , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <484EA8DE.8020005@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D58C1.1090108@sun.com> <484E9A88.7CB5C77E@nrubsig.org> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 1102 Roland Mainz wrote: > The trouble is that this increases the workload of a simple "make > OS/Net+SFWNV 64bit clean by switching to 64bit binaries on 64bit-only > platforms" by a factor of at least _three_ (delivering twice the number > of binaries, do the matching testing _and_ implementing packaging > changes (and the testing for it)). So is this important or not ? If it is important then please provide a spec for what you propose and explain where the value is. Note I'm not saying I object I just sill haven't seen an actual spec and this is wasting your time and the time of ARC members by continuing to try and discuss this case without a proper spec. Please work with your case sponsor to get a proper detailed spec in place and lets start with a fasttrack. > This is technically ARC'able but no > longer implementable for a single contributor (at least not if we intend > to crawl over both trees and clean them up). I don't see any reason why it isn't implementable by a single contributor and in any case that isn't relevant for the architecture review. -- Darren J Moffat From roland.mainz@nrubsig.org Tue Jun 10 09:24:39 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AGOcF7026930 for ; Tue, 10 Jun 2008 09:24:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5AGOUg7028567; Tue, 10 Jun 2008 17:24:34 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900D039KY3200@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jun 2008 09:24:34 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900MBA9KXYEC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jun 2008 09:24:33 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5AGOXPi007416; Tue, 10 Jun 2008 16:24:33 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-555220; Tue, 10 Jun 2008 16:24:33 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-125092; Tue, 10 Jun 2008 16:24:32 +0000 (Z) Received: from mail-in-09.arcor-online.net ([151.189.21.49] [151.189.21.49]) by relay1i.sun.com with ESMTP id BT-MMP-7797255; Tue, 10 Jun 2008 16:24:32 +0000 (Z) Received: from mail-in-11-z2.arcor-online.net (mail-in-11-z2.arcor-online.net [151.189.8.28]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 836B830285B; Tue, 10 Jun 2008 18:24:31 +0200 (CEST) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mail-in-11-z2.arcor-online.net (Postfix) with ESMTP id 6DBB83465A8; Tue, 10 Jun 2008 18:24:31 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-029-194.pools.arcor-ip.net [84.59.29.194]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 43825104B28; Tue, 10 Jun 2008 18:24:31 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m5AGORbA002943; Tue, 10 Jun 2008 18:24:28 +0200 (CEST) Date: Tue, 10 Jun 2008 18:24:27 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351SelfReview] Sender: gisburn@jupiterb48.nrubsig.org To: Joseph Kowalski Cc: Bart Smaalders , "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher Message-id: <484EAABB.7739612F@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.93.1/7417/Tue Jun 10 03:14:29 2008 on mail-in-01.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> Status: RO Content-Length: 670 Joseph Kowalski wrote: > > I'm sorry. I was supposed to contact you after the last PSARC meeting. > > There is no serious fast-track specification for this case. If we are > unable to proceed with out one. The project team needs to produce one. > > At a minimum, such a proposal needs a very clear list of the effected > utilities and the rationale for the list of effected utilities. Does that mean I have to make an ARC case for _each_ _single_ _binariy_ I make 64bit clean ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From gdamore@sun.com Tue Jun 10 10:16:48 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AHGl2Q001171 for ; Tue, 10 Jun 2008 10:16:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5AHGkv8045765 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jun 2008 11:16:47 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900I0ZBZY8T00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 10:16:46 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900H24BZXUJ20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 10:16:45 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5AHGjvq013806 for ; Tue, 10 Jun 2008 10:16:45 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900J01BTPNJ00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 10:16:45 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K29006F5BZUNPI0@fe-sfbay-09.sun.com>; Tue, 10 Jun 2008 10:16:43 -0700 (PDT) Date: Tue, 10 Jun 2008 10:15:49 -0700 From: "Garrett D'Amore" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351SelfReview] In-reply-to: <484EAABB.7739612F@nrubsig.org> Sender: Garrett.Damore@sun.com To: Roland Mainz Cc: Joseph Kowalski , Bart Smaalders , PSARC-ext@sun.com, John Plocher Message-id: <484EB6C5.5000108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1016 Roland Mainz wrote: > Joseph Kowalski wrote: > >> I'm sorry. I was supposed to contact you after the last PSARC meeting. >> >> There is no serious fast-track specification for this case. If we are >> unable to proceed with out one. The project team needs to produce one. >> >> At a minimum, such a proposal needs a very clear list of the effected >> utilities and the rationale for the list of effected utilities. >> > > Does that mean I have to make an ARC case for _each_ _single_ _binariy_ > I make 64bit clean ? > No. Two points: 1) Making a binary 64-bit "clean", but not delivering a 64-bit binary (still just delivering the 32-bit binary) is just a bug fix, and well below ARC radar. You can do that anytime you like, subject to CTeam. 2) If you're going to deliver 64-bit binaries, you can provide a single case listing multiple binaries. If you're also removing (or converting) a 32-bit binary, please make that explicit in the case. -- Garrett > ---- > > Bye, > Roland > > From roland.mainz@nrubsig.org Tue Jun 10 10:19:10 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AHJ9Wk001241 for ; Tue, 10 Jun 2008 10:19:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5AHJ2c7046678; Tue, 10 Jun 2008 11:19:07 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K290000XC3T2G00@brm-avmta-1.central.sun.com>; Tue, 10 Jun 2008 11:19:05 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900DKBC3RQQ80@brm-avmta-1.central.sun.com>; Tue, 10 Jun 2008 11:19:04 -0600 (MDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5AHEvGu017398; Tue, 10 Jun 2008 17:19:03 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-468913; Tue, 10 Jun 2008 17:19:03 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-25058148; Tue, 10 Jun 2008 17:19:02 +0000 (Z) Received: from mail-in-08.arcor-online.net ([151.189.21.48] [151.189.21.48]) by relay4i.sun.com with ESMTP id BT-MMP-116095; Tue, 10 Jun 2008 17:19:02 +0000 (Z) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id 72B3327AC92; Tue, 10 Jun 2008 19:19:01 +0200 (CEST) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id 610446BFE9; Tue, 10 Jun 2008 19:19:01 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-029-194.pools.arcor-ip.net [84.59.29.194]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id DF4A62BB6FF; Tue, 10 Jun 2008 19:19:00 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m5AHIvfe002956; Tue, 10 Jun 2008 19:18:58 +0200 (CEST) Date: Tue, 10 Jun 2008 19:18:57 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] Sender: gisburn@jupiterb48.nrubsig.org To: Darren J Moffat Cc: "Garrett D'Amore" , Bart Smaalders , PSARC-ext@sun.com, John Plocher , Joseph Kowalski Message-id: <484EB781.34A63BEC@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.93/7423/Tue Jun 10 17:53:05 2008 on mail-in-08.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.088sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D58C1.1090108@sun.com> <484E9A88.7CB5C77E@nrubsig.org> <484EA8DE.8020005@Sun.COM> Status: RO Content-Length: 2928 Darren J Moffat wrote: > Roland Mainz wrote: > > The trouble is that this increases the workload of a simple "make > > OS/Net+SFWNV 64bit clean by switching to 64bit binaries on 64bit-only > > platforms" by a factor of at least _three_ (delivering twice the number > > of binaries, do the matching testing _and_ implementing packaging > > changes (and the testing for it)). > > So is this important or not ? If it is important then please provide a > spec for what you propose and explain where the value is. The value in this case would be that the Solaris userland could support platforms which are 64bit only. At one point OpenSolaris.org&&Sun try to encourage people to start new ports but on the other side such projects have a very hard time since they have to implement artificial 32bit support first (if this is possible, e.g. some hardware architectures simply cannot support 32bit and we already lost a port in the initial stages after the interested party realised that they have to do the "cleanup" themselves) to get the userland running. As a (nice) side-effect we get some abilities from the 64bit land, e.g. high-resolution timestamps, the abilty to process more than 2GB of memory within the application itself etc. ... but my main interest is to get the code 64bit clean. > Note I'm not saying I object I just sill haven't seen an actual spec and > this is wasting your time and the time of ARC members by continuing to > try and discuss this case without a proper spec. Please work with your > case sponsor to get a proper detailed spec in place and lets start with > a fasttrack. I'll try to build one with Plocher... > > This is technically ARC'able but no > > longer implementable for a single contributor (at least not if we intend > > to crawl over both trees and clean them up). > > I don't see any reason why it isn't implementable by a single > contributor and in any case that isn't relevant for the architecture review. It is relevant for ARC to come up with a working architecture and _not_ force people or teams to boil the ocean in one large step (preferably I want only to work on the _code_ and get it tested without dealing with the package system at all (at least it's serious problem with SFWNV which currently doesn't support incremental rebuilds and therefore eating up engineering time (I'm trying to fix that but it will need some time until I reach that point in my ToDo list))) ... In the meantime I have another question: A couple of people pointed out it may be the case that ARC doesn't even need to be involved in such a project at all since the ARC'ed interfaces don't change (unless the binaries are explicitly labelled as "32bit" in an ARC case (which is usually not the case)) ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From roland.mainz@nrubsig.org Tue Jun 10 10:29:39 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AHTdeS001625 for ; Tue, 10 Jun 2008 10:29:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5AHTYS4004463; Tue, 10 Jun 2008 10:29:39 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900023CLETW00@brm-avmta-1.central.sun.com>; Tue, 10 Jun 2008 11:29:38 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900D5JCLDQXA0@brm-avmta-1.central.sun.com>; Tue, 10 Jun 2008 11:29:37 -0600 (MDT) Received: from relay17i.sun.com (ip127.net129179-4.block1.us.syntegra.com [129.179.4.127]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5AHTbdn002193; Tue, 10 Jun 2008 17:29:37 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay17i.sun.com with ESMTP id BT-MMP-528056; Tue, 10 Jun 2008 17:29:37 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-33695549; Tue, 10 Jun 2008 17:29:36 +0000 (Z) Received: from mail-in-08.arcor-online.net ([151.189.21.48] [151.189.21.48]) by relay1i.sun.com with ESMTP id BT-MMP-7826166; Tue, 10 Jun 2008 17:29:36 +0000 (Z) Received: from mail-in-19-z2.arcor-online.net (mail-in-19-z2.arcor-online.net [151.189.8.36]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id AA61D27B339; Tue, 10 Jun 2008 19:29:34 +0200 (CEST) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mail-in-19-z2.arcor-online.net (Postfix) with ESMTP id A64686BD3B; Tue, 10 Jun 2008 19:29:34 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-029-194.pools.arcor-ip.net [84.59.29.194]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 6C069104CD2; Tue, 10 Jun 2008 19:29:34 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m5AHTVUh002962; Tue, 10 Jun 2008 19:29:31 +0200 (CEST) Date: Tue, 10 Jun 2008 19:29:31 +0200 From: Roland Mainz Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Joseph Kowalski , Bart Smaalders , PSARC-ext@sun.com, John Plocher Message-id: <484EB9FB.78159F03@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.93.1/7423/Tue Jun 10 17:53:05 2008 on mail-in-01.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.363sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> Status: RO Content-Length: 1899 Garrett D'Amore wrote: > Roland Mainz wrote: > > Joseph Kowalski wrote: > >> I'm sorry. I was supposed to contact you after the last PSARC meeting. > >> > >> There is no serious fast-track specification for this case. If we are > >> unable to proceed with out one. The project team needs to produce one. > >> > >> At a minimum, such a proposal needs a very clear list of the effected > >> utilities and the rationale for the list of effected utilities. > > > > Does that mean I have to make an ARC case for _each_ _single_ _binariy_ > > I make 64bit clean ? > > No. Two points: > > 1) Making a binary 64-bit "clean", but not delivering a 64-bit binary > (still just delivering the 32-bit binary) is just a bug fix, and well > below ARC radar. You can do that anytime you like, subject to CTeam. Erm... I don't want to do the sisiphos work of doing the fixing and then have other people to undo them by accident. If I make the code 64bit clean I'd like to have a "safeguard" in place that noone can easily break it anymore... and the obvious "safeguard" is to just ship the 64bit binaries on platforms which only have a 64bit kernel anyway (which applies to SPARC([1]) and the Solaris port which shall-not-be-named). [1]=(SPARC is actually a good choice since it enforces the natural alignment of datatypes which is needed for some ports (but not all, e.g. AMD64 doesn't require this)) > 2) If you're going to deliver 64-bit binaries, you can provide a single > case listing multiple binaries. Technically - in the long term - this would include almost everything delievred by OS/Net+SFWNV. > If you're also removing (or converting) > a 32-bit binary, please make that explicit in the case. See above. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From gdamore@Sun.COM Tue Jun 10 10:52:28 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AHqRfO002270 for ; Tue, 10 Jun 2008 10:52:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5AHqNOU007830 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 01:52:26 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K290020HDNDGW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 11:52:25 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900DFPDNCR1B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 11:52:24 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5AHqOjV019636 for ; Tue, 10 Jun 2008 10:52:24 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900501D6LTS00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 10:52:24 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K29003MZDN7AS50@fe-sfbay-10.sun.com>; Tue, 10 Jun 2008 10:52:20 -0700 (PDT) Date: Tue, 10 Jun 2008 10:51:27 -0700 From: "Garrett D'Amore" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484EB9FB.78159F03@nrubsig.org> Sender: Garrett.Damore@Sun.COM To: Roland Mainz Cc: Joseph Kowalski , Bart Smaalders , PSARC-ext@Sun.COM, John Plocher Message-id: <484EBF1F.9040504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2115 What I think I understand from this case, is that part of rationale for this work, is that there are emerging platforms where supporting *any* 32-bit userland is problematic or impossible. Part of the goal, then, is to utilize SPARC to enforce that we always have a 64-bit version of all of the userland tools (or at least all of the core tools). I've confirmed this via IRC with Roland. In order for that to be meaningful, I think we'd have to have a new policy requiring that at least tools required for single user (and probably a significant set beyond that) be 64-bit clean. That sounds like a new Big Rule, requiring a written opinion to me. So, I'm pressing the derail button. Project team (Roland), *please* don't despair. Derailing doesn't mean that the case will not be successful, it only means that we need to understand the full scope of the problem, discuss it, and write a written opinion, possibly resulting in the creation of a new Big Rule. What I'd like to see in full case materials to be presented is: 1) the above rationale made explicit 2) some definition/clarification for deciding whether the Big Rule applies to a project or not (the boundary probably extends beyond single user mode, but how far beyond?) 3) an initial list of tools (not in e-mail, but an itemized list deposited in the case directory) 4) analysis of big-picture performance issues, if any (does 64-bit run faster, or slower? maybe run a some test of boot time analysis.) 5) a rough estimate in the increase of the size of the media/miniroot for the SPARC port 6) some thought given to future views on amd64 -- will such a direction ever make sense for amd64 as well? 7) if you are going to use a phased approach to delivery (fixing a few binaries at a time), as I suspect you will want to (just to make the problem tractable), then a statement to that effect. (that will avoid you needing to come back to ARC again for this same issue.) I realize that's a non-trivial amount of effort, but I think at the end of the day, it will result in higher quality decision making. -- Garrett From John.Plocher@sun.com Tue Jun 10 11:39:51 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AIdojY003774 for ; Tue, 10 Jun 2008 11:39:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5AIdfcB002091 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jun 2008 19:39:49 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K290050FFUDVK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 12:39:49 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900DV2FUCQQC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 12:39:48 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5AIdmpN017610 for ; Tue, 10 Jun 2008 11:39:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900701F0CXU00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 11:39:48 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2900GCXFUBG670@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 11:39:48 -0700 (PDT) Date: Tue, 10 Jun 2008 11:39:46 -0700 From: John Plocher Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484EBF1F.9040504@sun.com> Sender: John.Plocher@sun.com To: "Garrett D'Amore" Cc: Roland Mainz , PSARC-ext@sun.com Message-id: <484ECA72.3000503@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 785 [Roland and I are bouncing a proposal back and forth...] Garrett D'Amore wrote: > 4) analysis of big-picture performance issues, if any (does 64-bit run > faster, or slower? maybe run a some test of boot time analysis.) IIRC, the SPARC impact was "doesn't run faster" combined with "takes more disk space", rather than "runs significantly slower". > 5) a rough estimate in the increase of the size of the media/miniroot > for the SPARC port While interesting, this is IMO not an architectural issue, not part of this case (which isn't proposing to make a complete 64-bit miniroot), and with the way we are going with IPS and the size of disks (CD, DVD and rust) this is probably not a practical concern even if it ends up doubling the size (which I doubt it will). -John From jek3@sun.com Tue Jun 10 11:46:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AIkIu2004122 for ; Tue, 10 Jun 2008 11:46:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5AIkGog000269; Tue, 10 Jun 2008 11:46:17 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900K13G55IT00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jun 2008 11:46:17 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900DDJG5452E0@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jun 2008 11:46:16 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5AIkFpM597795; Tue, 10 Jun 2008 11:46:16 -0700 (PDT) Date: Tue, 10 Jun 2008 08:48:54 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351SelfReview] In-reply-to: <484EAABB.7739612F@nrubsig.org> To: Roland Mainz Cc: Bart Smaalders , "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher Message-id: <484ECC96.6020004@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1398 Roland Mainz wrote: > Joseph Kowalski wrote: > >> I'm sorry. I was supposed to contact you after the last PSARC meeting. >> >> There is no serious fast-track specification for this case. If we are >> unable to proceed with out one. The project team needs to produce one. >> >> At a minimum, such a proposal needs a very clear list of the effected >> utilities and the rationale for the list of effected utilities. >> > > Does that mean I have to make an ARC case for _each_ _single_ _binariy_ > I make 64bit clean ? > Not at all. We are just asking for a clear specification for which binaries you are proposing to deliver as 64-bit objects. For example, the only mention of bash is in the e-mail subject line. :-) You could also craft the proposal as "this is a blanket case allowing any binary to be produced as a 64-bit ELF". That's probably the best thing to do, but it would certainly be a full case. I alluded to CLIP. Unfortunately, that was read by some as a reference to the actual content. The allusion was about the need for rules and guidelines so that latter changes wouldn't need additional review. As Darren said, we can't evaluate something which isn't clearly described. Also, let's please be careful to not confuse "64-bit clean" and "delivered as a 64-bit object". If it just a matter of making these 64-bit clean, go forth and do so. - jek3 From jek3@sun.com Tue Jun 10 11:52:47 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AIqlBc004355 for ; Tue, 10 Jun 2008 11:52:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5AIqbH0007649; Tue, 10 Jun 2008 19:52:43 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900403GFUVV00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jun 2008 11:52:42 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K29003P7GFTSG00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jun 2008 11:52:41 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5AIqeJK599515; Tue, 10 Jun 2008 11:52:40 -0700 (PDT) Date: Tue, 10 Jun 2008 08:55:19 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351SelfReview] In-reply-to: <484EAABB.7739612F@nrubsig.org> To: Roland Mainz Cc: Bart Smaalders , "Garrett D'Amore" , PSARC-ext@sun.com, John Plocher Message-id: <484ECE17.9000900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1072 Roland Mainz wrote: > Joseph Kowalski wrote: > >> I'm sorry. I was supposed to contact you after the last PSARC meeting. >> >> There is no serious fast-track specification for this case. If we are >> unable to proceed with out one. The project team needs to produce one. >> >> At a minimum, such a proposal needs a very clear list of the effected >> utilities and the rationale for the list of effected utilities. >> > > Does that mean I have to make an ARC case for _each_ _single_ _binariy_ > I make 64bit clean ? > Humm,.... Despite my earlier response (like 3 minutes ago), yea. Without the case which defines the "rules", we need to see a case for "each grouping" of _each_ _single_ _binary_ you are proposing to deliver as 64-bit objects. After a fairly small number of these (3? 5? 10?), the precedent will be established. So, you have a couple of choices as how to proceed: 1) Create a case that established the precedent. (Such as CLIP.) 2) Keep creating fast-tracks until when taken together we have a precedent. - jek3 From gdamore@sun.com Tue Jun 10 11:55:07 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AIt7UD004685 for ; Tue, 10 Jun 2008 11:55:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5AIt3pb013508 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jun 2008 12:55:07 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900K0RGJTVR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 11:55:05 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900DYPGJR4XD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 11:55:03 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5AIt33q019716 for ; Tue, 10 Jun 2008 11:55:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900H01FV1WN00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 11:55:03 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2900FYLGJLHV00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 11:54:57 -0700 (PDT) Date: Tue, 10 Jun 2008 11:54:04 -0700 From: "Garrett D'Amore" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484ECA72.3000503@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Roland Mainz , PSARC-ext@sun.com Message-id: <484ECDCC.3010304@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2263 John Plocher wrote: > [Roland and I are bouncing a proposal back and forth...] > > Garrett D'Amore wrote: >> 4) analysis of big-picture performance issues, if any (does 64-bit >> run faster, or slower? maybe run a some test of boot time analysis.) > > IIRC, the SPARC impact was "doesn't run faster" combined with > "takes more disk space", rather than "runs significantly slower". > >> 5) a rough estimate in the increase of the size of the media/miniroot >> for the SPARC port > > While interesting, this is IMO not an architectural issue, not part > of this case (which isn't proposing to make a complete 64-bit > miniroot), and with the way we are going with IPS and the size of > disks (CD, DVD and rust) this is probably not a practical concern > even if it ends up doubling the size (which I doubt it will). Point taken. And yes, both of the issues raised above are not strictly architectural. But if it does have a significant (and "significant" can vary from one ARC member to the next) increase in size or impact to performance, then I think we'd like to know about it. Part of my concern here is that ARC review is really the only way that issues like this (which may have impact well beyond architecture, and touch a lot of different projects/consumers) can get published/recorded. CTeam review is basically "private" to Sun, and AFAIK not published in a way that others can find it. Doubling the size of the install media requirements, while not an ARC concern directly, isn't something that I'd like to see 'hidden' from view. (Honestly, I suspect the increase in size to be on the order of 20%, and as you noted, probably not a real cause for concern. You might even be able to stop shipping some 32-bit private libraries, more analysis would be required.) That said, certainly addressing the "possible cause for concern" (such as this) in advance in the case materials, with text like what you provided above, can't hurt the review, and may shut down objections before they are raised. Which is also part of the reason why I added it to the list of things I'd like to see. FWIW, it sounds like Roland's goals here are worthwhile, and I'd like to see him succeed on this with a minimum of bruises. -- Garrett From jek3@Sun.COM Tue Jun 10 12:36:54 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AJasVf006197 for ; Tue, 10 Jun 2008 12:36:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5AJairA026333; Tue, 10 Jun 2008 20:36:52 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900M03IHEI700@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jun 2008 12:36:50 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900LUAIHDIR00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jun 2008 12:36:49 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5AJakps607259; Tue, 10 Jun 2008 12:36:47 -0700 (PDT) Date: Tue, 10 Jun 2008 09:39:25 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484ECA72.3000503@Sun.Com> To: John Plocher Cc: "Garrett D'Amore" , Roland Mainz , PSARC-ext@Sun.COM Message-id: <484ED86D.509@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1237 John Plocher wrote: > [Roland and I are bouncing a proposal back and forth...] > > Garrett D'Amore wrote: >> 4) analysis of big-picture performance issues, if any (does 64-bit >> run faster, or slower? maybe run a some test of boot time analysis.) > > IIRC, the SPARC impact was "doesn't run faster" combined with > "takes more disk space", rather than "runs significantly slower". +1 ARC review is only to cover speed and size issues when they are large enough to have some architectual impact. In my estimation, these don't qualify. >> 5) a rough estimate in the increase of the size of the media/miniroot >> for the SPARC port > > While interesting, this is IMO not an architectural issue, not part > of this case (which isn't proposing to make a complete 64-bit > miniroot), and with the way we are going with IPS and the size of > disks (CD, DVD and rust) this is probably not a practical concern > even if it ends up doubling the size (which I doubt it will). +0.8 I agree that this isn't an architecture issue, but its not just rust. At about nv60, the GUI installation died on 512 mb laptops because the miniroot couldn't run (in gui mode). Its not an architectual concern, but it is a practical concern. - jek3 From Joerg.Schilling@fokus.fraunhofer.de Tue Jun 10 13:24:34 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AKOXYg010095 for ; Tue, 10 Jun 2008 13:24:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5AKOTI7004226; Wed, 11 Jun 2008 04:24:31 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900D07KOSLD00@brm-avmta-1.central.sun.com>; Tue, 10 Jun 2008 14:24:28 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K29008QIKORB030@brm-avmta-1.central.sun.com>; Tue, 10 Jun 2008 14:24:27 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5AKMwfE027354; Tue, 10 Jun 2008 20:24:27 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-50560; Tue, 10 Jun 2008 20:24:27 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-517795; Tue, 10 Jun 2008 20:24:25 +0000 (Z) Received: from mailgwb1.fraunhofer.de ([153.96.87.18] [153.96.87.18]) by relay1ib.sun.com with ESMTP id BT-MMP-602501; Tue, 10 Jun 2008 20:24:25 +0000 (Z) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id m5AKKOks009691; Tue, 10 Jun 2008 22:20:24 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5AKKMhL009635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jun 2008 22:20:23 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5AKKMP2012025; Tue, 10 Jun 2008 22:20:22 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 22:20:22 +0200 Date: Tue, 10 Jun 2008 22:20:22 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484ECA72.3000503@Sun.Com> To: John.Plocher@sun.com, gdamore@sun.com Cc: PSARC-ext@sun.com Message-id: <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 1.244sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 10 Jun 2008 20:20:22.0961 (UTC) FILETIME=[6941AA10:01C8CB37] Status: RO Content-Length: 2259 John Plocher wrote: > [Roland and I are bouncing a proposal back and forth...] > > Garrett D'Amore wrote: > > 4) analysis of big-picture performance issues, if any (does 64-bit run > > faster, or slower? maybe run a some test of boot time analysis.) > > IIRC, the SPARC impact was "doesn't run faster" combined with > "takes more disk space", rather than "runs significantly slower". This is correct, but NV_89 still does not offer the minimum amount of 64 bit binaries. In former times, we did neither have ls(1) nor find(1) available as 64 bit binary, so it was impossible to list files that need a 64 bit binary to even stat(2) the file. We now have ls(1) as 64 bit binary, so we are able to list the files. We still miss touch(1) in the list of 64 bit binaries in order to be able to correct the time stamps for problematic files. Back to the current case: there are programs that are known to be faster on sparc if compiled in 64 bit. This is in general true for all programs that know how to scan memory more efficiently if in 64 bit mode. A right grep(1) implementation could e.g. benefit from this. On amd64, all 64 bit binaries typically (with a few exceptions) run ~ 30% faster than their 32 bit couterparts. Shouldn't we take take care of this difference? Is there no way to treat amd64 different from sparcv9? > > 5) a rough estimate in the increase of the size of the media/miniroot > > for the SPARC port > > While interesting, this is IMO not an architectural issue, not part > of this case (which isn't proposing to make a complete 64-bit > miniroot), and with the way we are going with IPS and the size of > disks (CD, DVD and rust) this is probably not a practical concern > even if it ends up doubling the size (which I doubt it will). I would be interested in a better aligned installed system. I do not care that much how the installation is done unless the change could double the install speed. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From roland.mainz@nrubsig.org Tue Jun 10 14:30:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5ALUI2S012653 for ; Tue, 10 Jun 2008 14:30:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5ALUG38018190; Tue, 10 Jun 2008 14:30:17 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900I11NQGN000@brm-avmta-1.central.sun.com>; Tue, 10 Jun 2008 15:30:16 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K29008IYNQFBC80@brm-avmta-1.central.sun.com>; Tue, 10 Jun 2008 15:30:15 -0600 (MDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5ALUFLN026984; Tue, 10 Jun 2008 21:30:15 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-174062; Tue, 10 Jun 2008 21:30:14 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-24467; Tue, 10 Jun 2008 21:30:14 +0000 (Z) Received: from mail-in-14.arcor-online.net ([151.189.21.54] [151.189.21.54]) by relay1ib.sun.com with ESMTP id BT-MMP-623683; Tue, 10 Jun 2008 21:30:13 +0000 (Z) Received: from mail-in-14-z2.arcor-online.net (mail-in-14-z2.arcor-online.net [151.189.8.31]) by mail-in-14.arcor-online.net (Postfix) with ESMTP id EFD97187922; Tue, 10 Jun 2008 23:30:12 +0200 (CEST) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-14-z2.arcor-online.net (Postfix) with ESMTP id DE3AC100F7; Tue, 10 Jun 2008 23:30:12 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-029-194.pools.arcor-ip.net [84.59.29.194]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 874D81BF4E3; Tue, 10 Jun 2008 23:30:12 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m5ALU9kV003015; Tue, 10 Jun 2008 23:30:10 +0200 (CEST) Date: Tue, 10 Jun 2008 23:30:09 +0200 From: Roland Mainz Subject: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] Sender: gisburn@jupiterb48.nrubsig.org To: PSARC-ext@sun.com Cc: John.Plocher@sun.com, gdamore@sun.com Message-id: <484EF261.7AE75ECE@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.93/7407/Mon Jun 9 04:21:00 2008 on mail-in-04.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.295sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> Status: RO Content-Length: 764 Joerg Schilling wrote: > John Plocher wrote: > > [Roland and I are bouncing a proposal back and forth...] [snip] > We still miss touch(1) in the list of 64 bit binaries > in order to be able to correct the time stamps for problematic files. Well, I can fix that assuming we declare that a "bug fix", including the use of isaexec (the first person who says we need an ARC case will a) volunteer to fix the bug himself and will then b) be thrown in a pit with komodo dragons (and I'll make sure they're small so they need _days_ to finish the victim off)). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From jek3@sun.com Tue Jun 10 14:36:42 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5ALag2S012866 for ; Tue, 10 Jun 2008 14:36:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5ALaf7b060754; Tue, 10 Jun 2008 15:36:41 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900403O15DD00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jun 2008 14:36:41 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900LJRO15IT70@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jun 2008 14:36:41 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5ALad8b628527; Tue, 10 Jun 2008 14:36:40 -0700 (PDT) Date: Tue, 10 Jun 2008 11:39:19 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg Schilling Cc: John.Plocher@sun.com, gdamore@sun.com, PSARC-ext@sun.com Message-id: <484EF487.3030502@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1102 Joerg Schilling wrote: > On amd64, all 64 bit binaries typically (with a few exceptions) run ~ 30% > faster than their 32 bit couterparts. > > Shouldn't we take take care of this difference? Is there no way to treat amd64 > different from sparcv9? > Ah, the topic everyone seems to avoid talking about. There is a small set of "correction" issues on SPARC. There are *some* applications which are faster as 32-bit. There are *some* applications which are faster as 64-bits. All kind of worth a huge yawn. There is a significant performance issue on amd64 [1]. Its all about the registers. Unfortunately, since we still attempt to produce one "IA" distribution *and* support 32-bit IA processors, we are stuck at the lowest common denominator. Every Linix'ish distro I know of has both 64 and 32 bit variants. Sun has not shown a significant interest in producing a 64-bit, IA distribution. OpenSolaris certainly could. That said, its not this case, right? - jek3 [1] Replace "amd64" with your choice of: i386, i486, i586, i686, x86, ia86, ia64, x64, amd64, IA64,.... :-) From gdamore@sun.com Tue Jun 10 14:43:51 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5ALho4o013407 for ; Tue, 10 Jun 2008 14:43:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5ALhgbn023001 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jun 2008 22:43:49 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900J0BOD0NK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 15:43:48 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K29008QSOCZB080@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 15:43:47 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5ALhl2I027920 for ; Tue, 10 Jun 2008 14:43:47 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900A01NWMOR00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 14:43:47 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2900FLCOCY7N70@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 14:43:47 -0700 (PDT) Date: Tue, 10 Jun 2008 14:42:54 -0700 From: "Garrett D'Amore" Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484EF261.7AE75ECE@nrubsig.org> Sender: Garrett.Damore@sun.com To: Roland Mainz Cc: PSARC-ext@sun.com, John.Plocher@sun.com Message-id: <484EF55E.9090301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1355 Roland Mainz wrote: > Joerg Schilling wrote: > >> John Plocher wrote: >> >>> [Roland and I are bouncing a proposal back and forth...] >>> > [snip] > >> We still miss touch(1) in the list of 64 bit binaries >> in order to be able to correct the time stamps for problematic files. >> > > Well, I can fix that assuming we declare that a "bug fix", including the > use of isaexec (the first person who says we need an ARC case will a) > volunteer to fix the bug himself and will then b) be thrown in a pit > with komodo dragons (and I'll make sure they're small so they need > _days_ to finish the victim off)). > This is not architectural, but is the only way to fix this to use a 64-bit binary? Can't we fix it using uint64_t or somesuch in a 32-bit program? (I'm talking about the specific deficiency for /usr/bin/touch.) I'd like the fix to be available from a 32-bit environment as well as a 64-bit one, otherwise the "fix" is incomplete. -- Garrett PS: Roland, please take my advice and take the time to do things "the right way", which includes a complete ARC review of the 64-bit problems you're trying to solve. Attempting to do an end-run around ARC with a bunch of little cases to avoid providing the full picture is unlikely to be well received. > ---- > > Bye, > Roland > > From gdamore@sun.com Tue Jun 10 14:48:32 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5ALmWYa013716 for ; Tue, 10 Jun 2008 14:48:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5ALmW95064513 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jun 2008 15:48:32 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900409OKUV000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 14:48:30 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900LQOOKRIA70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 14:48:28 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5ALmRt1017930 for ; Tue, 10 Jun 2008 14:48:27 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900A01NWMOR00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 14:48:27 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2900EZHOKPAT30@fe-sfbay-09.sun.com>; Tue, 10 Jun 2008 14:48:25 -0700 (PDT) Date: Tue, 10 Jun 2008 14:47:33 -0700 From: "Garrett D'Amore" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484EF487.3030502@sun.com> Sender: Garrett.Damore@sun.com To: Joseph Kowalski Cc: Joerg Schilling , John.Plocher@sun.com, PSARC-ext@sun.com Message-id: <484EF675.8080704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF487.3030502@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1999 Joseph Kowalski wrote: > Joerg Schilling wrote: >> On amd64, all 64 bit binaries typically (with a few exceptions) run ~ >> 30% faster than their 32 bit couterparts. >> >> Shouldn't we take take care of this difference? Is there no way to >> treat amd64 >> different from sparcv9? >> > > Ah, the topic everyone seems to avoid talking about. > > There is a small set of "correction" issues on SPARC. There are > *some* applications which are faster as 32-bit. There are *some* > applications which are faster as 64-bits. All kind of worth a huge yawn. > > There is a significant performance issue on amd64 [1]. Its all about > the registers. Unfortunately, since we still attempt to produce one > "IA" distribution *and* support 32-bit IA processors, we are stuck at > the lowest common denominator. > > Every Linix'ish distro I know of has both 64 and 32 bit variants. Sun > has not shown a significant interest in producing a 64-bit, IA > distribution. OpenSolaris certainly could. > > That said, its not this case, right? I don't know if its this case or not. I derailed it, and case materials need to be supplied. The idea that we could "fix" some of the 32-bit performance problems, or offer an optional 64-bit only distro, certainly has a certain amount of appeal. There's a whole other issue, which is that for a lot of interfaces, thunking between 64-bit and 32-bit structures when crossing the userland/kernel boundary is somewhat expensive. But, due to compatibility guarantees, I don't think we can eliminate the code in the kernel to support it-- but we can reduce the amount that it gets *used*. (There may be some private ioctls which could be entirely cleaned up/made 64-bit only, though. But only for drivers that don't require 32-bit userland support -- I'm not sure there are very many of those.) -- Garrett > > - jek3 > > [1] Replace "amd64" with your choice of: i386, i486, i586, i686, > x86, ia86, ia64, x64, amd64, IA64,.... :-) From jek3@sun.com Tue Jun 10 14:57:18 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5ALvHkb014549 for ; Tue, 10 Jun 2008 14:57:17 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5ALvBos028094; Tue, 10 Jun 2008 22:57:15 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K290010NOZEG900@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jun 2008 14:57:14 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K290019HOZC2N10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jun 2008 14:57:12 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5ALvBBk631837; Tue, 10 Jun 2008 14:57:11 -0700 (PDT) Date: Tue, 10 Jun 2008 11:59:50 -1000 From: Joseph Kowalski Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484EF261.7AE75ECE@nrubsig.org> To: Roland Mainz Cc: PSARC-ext@sun.com, John.Plocher@sun.com, gdamore@sun.com Message-id: <484EF956.1030705@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 916 Roland Mainz wrote: > Well, I can fix that assuming we declare that a "bug fix", including the > use of isaexec (the first person who says we need an ARC case will a) > volunteer to fix the bug himself and will then b) be thrown in a pit > with komodo dragons (and I'll make sure they're small so they need > _days_ to finish the victim off)). > See: http://www.cbsnews.com/stories/2008/06/09/world/main4162807.shtml At the danger of being thrown to these dragons, it would be useful to capture the list of items where a 64-bit version is needed. Perhaps just a CR which listed the known violators. I suspect that the current situation is that they are captured in a number of CRs, which probably accounts for this slow trickle of "BTW: ..." postings. (I mention this that something in the sac database would be particularly useful, but that certainly isn't a requirement.) Just a thought.... - jek3 From jek3@sun.com Tue Jun 10 15:20:16 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AMKFfZ015866 for ; Tue, 10 Jun 2008 15:20:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5AMKCZl005511; Tue, 10 Jun 2008 23:20:13 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900607Q1O9Q00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jun 2008 15:20:12 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2900LJLQ1NIS80@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Jun 2008 15:20:11 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5AMKAba634620; Tue, 10 Jun 2008 15:20:10 -0700 (PDT) Date: Tue, 10 Jun 2008 12:22:49 -1000 From: Joseph Kowalski Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484EF675.8080704@sun.com> To: "Garrett D'Amore" Cc: Joerg Schilling , John.Plocher@sun.com, PSARC-ext@sun.com Message-id: <484EFEB9.7070607@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF487.3030502@sun.com> <484EF675.8080704@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 913 Garrett D'Amore wrote: > I don't know if its this case or not. I derailed it, and case > materials need to be supplied. The idea that we could "fix" some of > the 32-bit performance problems, or offer an optional 64-bit only > distro, certainly has a certain amount of appeal. Its not this case or any other case we should/could create. (Except at the very, low extreme) We review projects proposed by project teams. We can suggest in Advice that such a project team should be formed. We can not dictate that projects be created [1]. BTW: What is "an optional ... distro"? - jek3 [1] I remember that the ARCs have made the statement "we will not approve any projects in this specific area until XXX is fixed". The biggest one I remember was an LDAP disaster Solaris had about a decade ago, but this is far from the general case and completely inappropriate for this **marketing** decision. From gdamore@sun.com Tue Jun 10 15:25:59 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5AMPxIR016780 for ; Tue, 10 Jun 2008 15:25:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5AMPtwH008195 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jun 2008 23:25:58 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900M0BQB8XK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 16:25:56 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K29008WXQB8B0A0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 16:25:56 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5AMPuqN005521 for ; Tue, 10 Jun 2008 15:25:56 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900A01PYH5N00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 15:25:56 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2900ET8QB7ATD0@fe-sfbay-09.sun.com>; Tue, 10 Jun 2008 15:25:55 -0700 (PDT) Date: Tue, 10 Jun 2008 15:25:03 -0700 From: "Garrett D'Amore" Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484EFEB9.7070607@sun.com> Sender: Garrett.Damore@sun.com To: Joseph Kowalski Cc: Joerg Schilling , John.Plocher@sun.com, PSARC-ext@sun.com Message-id: <484EFF3F.6000008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF487.3030502@sun.com> <484EF675.8080704@sun.com> <484EFEB9.7070607@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2058 Joseph Kowalski wrote: > Garrett D'Amore wrote: >> I don't know if its this case or not. I derailed it, and case >> materials need to be supplied. The idea that we could "fix" some of >> the 32-bit performance problems, or offer an optional 64-bit only >> distro, certainly has a certain amount of appeal. > > Its not this case or any other case we should/could create. (Except > at the very, low extreme) We review projects proposed by project > teams. We can suggest in Advice that such a project team should be > formed. We can not dictate that projects be created [1]. What I meant is, the project team has not specified *any* case materials yet. I derailed based upon an understanding of what the case intended to do (and confirmation with project teams), but now that its derailed, lets avoid assumptions about what this case is or is not about until the project team gets a chance to provide us with futher materials. > > BTW: What is "an optional ... distro"? I had in mind that users could download a version of OpenSolaris which only had the 64-bit binaries, and lacked any support for running a 32-bit kernel. Obviously, since we still have to support 32-bit processors, we would have to offer this *in addition* to the current dual 32/64- bit distributions we offer. (At least until someone EOF's support for older pentiums and earlier. Since I think you can still buy 32-bit only systems today, I don't imagine that EOF to be forthcoming soon.) And on that note, lets just table this whole case until we get an update from the project team. Seems kind of fruitless to continue further discussion until we know exactly what the proposal on the table is. -- Garrett > > - jek3 > > [1] I remember that the ARCs have made the statement "we will not > approve any projects in this specific area until XXX is fixed". The > biggest one I remember was an LDAP disaster Solaris had about a decade > ago, but this is far from the general case and completely > inappropriate for this **marketing** decision. From John.Plocher@Sun.COM Tue Jun 10 17:48:02 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5B0m2vg024140 for ; Tue, 10 Jun 2008 17:48:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5B0m1O0026230 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Jun 2008 17:48:01 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2900B01WW06100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 18:48:00 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K29006MRWVZOB30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 18:47:59 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5B0lxkE006791 for ; Tue, 10 Jun 2008 17:47:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900H01WPCSM00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Jun 2008 17:47:59 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2900K60WVZNPG0@fe-sfbay-10.sun.com>; Tue, 10 Jun 2008 17:47:59 -0700 (PDT) Date: Tue, 10 Jun 2008 17:47:57 -0700 From: John Plocher Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484EFF3F.6000008@sun.com> Sender: John.Plocher@Sun.COM To: "Garrett D'Amore" Cc: Joseph Kowalski , Joerg Schilling , PSARC-ext@Sun.COM Message-id: <484F20BD.8090404@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF487.3030502@sun.com> <484EF675.8080704@sun.com> <484EFEB9.7070607@sun.com> <484EFF3F.6000008@sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 407 Garrett D'Amore wrote: > I had in mind that users could download a version of OpenSolaris which > only had the 64-bit binaries The IPS stuff lets (will let?) us build "fat" packages with SPARC, x64, PPC, ... 32 and 64 bit content and put it into the IPS repos, where the installer could download only the image specific bits that are needed by the platform in use. As they say, not this case. -John From Joerg.Schilling@fokus.fraunhofer.de Wed Jun 11 03:28:46 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BASjFH004456 for ; Wed, 11 Jun 2008 03:28:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BASfm9023904; Wed, 11 Jun 2008 11:28:41 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2A00I07NRTBX00@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jun 2008 03:28:41 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2A00912NRSK8D0@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Jun 2008 03:28:40 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5BASdFP023968; Wed, 11 Jun 2008 10:28:40 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-31000; Wed, 11 Jun 2008 10:28:39 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-26273908; Wed, 11 Jun 2008 10:28:39 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay4i.sun.com with ESMTP id BT-MMP-1009406; Wed, 11 Jun 2008 10:28:38 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw12] (8.14.2+/8.14.2) with ESMTP id m5BAJt9d007705; Wed, 11 Jun 2008 12:19:55 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5BAJshP007696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jun 2008 12:19:54 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5BAJrBQ023312; Wed, 11 Jun 2008 12:19:53 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 12:19:54 +0200 Date: Wed, 11 Jun 2008 12:19:53 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484EB781.34A63BEC@nrubsig.org> To: roland.mainz@nrubsig.org, Darren.Moffat@sun.com Cc: PSARC-ext@sun.com, plocher@sac.sfbay.sun.com, jek3@sun.com, gdamore@sun.com, Bart.Smaalders@sun.com Message-id: <484fa6c9.pf+GxOocg6dgntV2%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.082sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D58C1.1090108@sun.com> <484E9A88.7CB5C77E@nrubsig.org> <484EA8DE.8020005@Sun.COM> <484EB781.34A63BEC@nrubsig.org> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 11 Jun 2008 10:19:54.0097 (UTC) FILETIME=[B0CB0E10:01C8CBAC] Status: RO Content-Length: 1474 Roland Mainz wrote: > The value in this case would be that the Solaris userland could support > platforms which are 64bit only. At one point OpenSolaris.org&&Sun try to > encourage people to start new ports but on the other side such projects > have a very hard time since they have to implement artificial 32bit > support first (if this is possible, e.g. some hardware architectures > simply cannot support 32bit and we already lost a port in the initial > stages after the interested party realised that they have to do the > "cleanup" themselves) to get the userland running. I did make diff(1) 64 bit clean 1.6 years ago, and it was definitely much more than a one hour trask: No prototypes, uninitialized variables, bad pointer casts.... If you like to work on other sources, do not expect this to be trivial and do not expect to see interest from people inside Sun. I tried to offer my ennhancememts but nobody was interested even though a 32 bit diff(1) may limit the max. file size to less than 100 MB if both files use very small line lengths. The max. file size of a 64 bit diff is only limited by the virtual amount of memory.... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Wed Jun 11 03:36:59 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BAax41004640 for ; Wed, 11 Jun 2008 03:36:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5BAav33026025; Wed, 11 Jun 2008 03:36:58 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2A00K13O5L1T00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Jun 2008 03:36:57 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2A0088ZO5KEO50@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Jun 2008 03:36:56 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5BAatCR013683; Wed, 11 Jun 2008 10:36:56 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay43i.sun.com with ESMTP id BT-MMP-495326; Wed, 11 Jun 2008 10:36:55 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-26283247; Wed, 11 Jun 2008 10:36:55 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay4i.sun.com with ESMTP id BT-MMP-961989; Wed, 11 Jun 2008 10:36:55 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw26] (8.14.2+/8.14.2) with ESMTP id m5BASpUP007111; Wed, 11 Jun 2008 12:28:51 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5BASoDx007108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jun 2008 12:28:51 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5BASofk023782; Wed, 11 Jun 2008 12:28:50 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 12:28:51 +0200 Date: Wed, 11 Jun 2008 12:28:50 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484EB9FB.78159F03@nrubsig.org> To: roland.mainz@nrubsig.org, gdamore@sun.com Cc: PSARC-ext@sun.com, plocher@sac.sfbay.sun.com, jek3@sun.com, Bart.Smaalders@sun.com Message-id: <484fa8e2.n4SB6+q7g5tNOCFM%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.074sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 11 Jun 2008 10:28:51.0158 (UTC) FILETIME=[F0E80F60:01C8CBAD] Status: RO Content-Length: 1056 Roland Mainz wrote: > [1]=(SPARC is actually a good choice since it enforces the natural > alignment of datatypes which is needed for some ports (but not all, e.g. > AMD64 doesn't require this)) My experience from making OpeenSolaris software 64 bit clean (sh, sccs*, diff) did not show up any such problem. The typical bugs in the software I fixed have been: - missing function prototypes - bad/missing pointer casts (e.g. ececl*()) - pointer/int assignements - unintialized variables (this also hit's 32 bit!!!!) - use of int where long or explicit (*int*_t) types would bee needed - incorrect printf() format strings In general, the state of many userland programs is still how people would expect it 20 years ago. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling@fokus.fraunhofer.de Wed Jun 11 08:17:44 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BFHhes010022 for ; Wed, 11 Jun 2008 08:17:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5BFHgZj011700; Wed, 11 Jun 2008 09:17:43 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00A0V15H5000@brm-avmta-1.central.sun.com>; Wed, 11 Jun 2008 09:17:41 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B005UL15GGX40@brm-avmta-1.central.sun.com>; Wed, 11 Jun 2008 09:17:41 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5BF2nc4019968; Wed, 11 Jun 2008 15:17:40 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay13i.sun.com with ESMTP id BT-MMP-86687; Wed, 11 Jun 2008 15:17:40 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-16056; Wed, 11 Jun 2008 15:17:38 +0000 (Z) Received: from mailgwb1.fraunhofer.de ([153.96.87.18] [153.96.87.18]) by relay1i.sun.com with ESMTP id BT-MMP-8298395; Wed, 11 Jun 2008 15:17:38 +0000 (Z) Received: from mailgwb1.fraunhofer.de (localhost [127.0.0.1]) by mailgwb1.fraunhofer.de[host mailgwb1] (8.14.2+/8.14.2) with ESMTP id m5BFDYY1022769; Wed, 11 Jun 2008 17:13:34 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgwb1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5BFDYHY022745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jun 2008 17:13:34 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5BFDXuE007169; Wed, 11 Jun 2008 17:13:34 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 17:13:34 +0200 Date: Wed, 11 Jun 2008 17:13:33 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484EF55E.9090301@sun.com> To: roland.mainz@nrubsig.org, gdamore@sun.com Cc: PSARC-ext@sun.com, John.Plocher@sun.com Message-id: <484feb9d.YHM+iMEOHMiv6Wej%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 1.174sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 11 Jun 2008 15:13:34.0126 (UTC) FILETIME=[B7261CE0:01C8CBD5] Status: RO Content-Length: 1131 "Garrett D'Amore" wrote: > Roland Mainz wrote: > > Joerg Schilling wrote: > > > >> John Plocher wrote: > >> > >>> [Roland and I are bouncing a proposal back and forth...] > >>> > > [snip] > > > >> We still miss touch(1) in the list of 64 bit binaries > >> in order to be able to correct the time stamps for problematic files. ... > This is not architectural, but is the only way to fix this to use a > 64-bit binary? Can't we fix it using uint64_t or somesuch in a 32-bit > program? (I'm talking about the specific deficiency for > /usr/bin/touch.) I'd like the fix to be available from a 32-bit > environment as well as a 64-bit one, otherwise the "fix" is incomplete. The only way to stat(2) such files is to use a 64 bit binary, so yes we need a 64 bit touch Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From gdamore@sun.com Wed Jun 11 08:37:33 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BFbX3h010417 for ; Wed, 11 Jun 2008 08:37:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BFbNo4005406 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 16:37:32 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00B0T22GGG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:37:28 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B0057X22FGX60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:37:27 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BFbQOI004415 for ; Wed, 11 Jun 2008 08:37:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00B011X1D000@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 08:37:26 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B0091V2265SG0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 08:37:18 -0700 (PDT) Date: Wed, 11 Jun 2008 08:36:22 -0700 From: "Garrett D'Amore" Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484feb9d.YHM+iMEOHMiv6Wej%Joerg.Schilling@fokus.fraunhofer.de> Sender: Garrett.Damore@sun.com To: Joerg Schilling Cc: roland.mainz@nrubsig.org, PSARC-ext@sun.com, John.Plocher@sun.com Message-id: <484FF0F6.1090307@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <484feb9d.YHM+iMEOHMiv6Wej%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1481 Joerg Schilling wrote: > "Garrett D'Amore" wrote: > > >> Roland Mainz wrote: >> >>> Joerg Schilling wrote: >>> >>> >>>> John Plocher wrote: >>>> >>>> >>>>> [Roland and I are bouncing a proposal back and forth...] >>>>> >>>>> >>> [snip] >>> >>> >>>> We still miss touch(1) in the list of 64 bit binaries >>>> in order to be able to correct the time stamps for problematic files. >>>> > ... > >> This is not architectural, but is the only way to fix this to use a >> 64-bit binary? Can't we fix it using uint64_t or somesuch in a 32-bit >> program? (I'm talking about the specific deficiency for >> /usr/bin/touch.) I'd like the fix to be available from a 32-bit >> environment as well as a 64-bit one, otherwise the "fix" is incomplete. >> > > The only way to stat(2) such files is to use a 64 bit binary, so yes we > need a 64 bit touch > Maybe we need to invent a new lstat64_2 or somesuch, that uses 64-bit time_t's. I certainly would like to see a fix that is available from 32-bit kernels, if at all possible. But this sounds like a bigger issue. I also remain unfond of the approach of turning a bunch of key programs in /usr/bin into isaexec() links. While the isaexec() approach was not unreasonable for a few utilities that aren't run frequently like prtconf, I don't think the solution scales well. -- Garrett > > > Jörg > > From John.Plocher@sun.com Wed Jun 11 08:53:24 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BFrN5i010676 for ; Wed, 11 Jun 2008 08:53:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5BFrJjf014452 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 23:53:22 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00C0V2SVNK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:53:19 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B005D72SVGX70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:53:19 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BFrJBS025691 for ; Wed, 11 Jun 2008 08:53:19 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00G012789E00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 08:53:18 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B006H02SL6W20@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 08:53:09 -0700 (PDT) Date: Wed, 11 Jun 2008 08:53:07 -0700 From: John Plocher Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484FF0F6.1090307@sun.com> Sender: John.Plocher@sun.com To: "Garrett D'Amore" Cc: Joerg Schilling , roland.mainz@nrubsig.org, PSARC-ext@sun.com Message-id: <484FF4E3.6020105@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <484feb9d.YHM+iMEOHMiv6Wej%Joerg.Schilling@fokus.fraunhofer.de> <484FF0F6.1090307@sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 565 Garrett D'Amore wrote: > I also remain unfond of the approach of turning a bunch of key programs > in /usr/bin into isaexec() links. While the isaexec() approach was not > unreasonable for a few utilities that aren't run frequently like > prtconf, I don't think the solution scales well. Maybe there is an opportunity to leverage IPS here - have it install the correct binaries from the repo (32, 64, x64, SPARC, Power, ARM...) based on the isaexec-abilities of the target platform. (i.e., don't do isaexec() at runtime, do it at install time :-) -John From binarycrusader@gmail.com Wed Jun 11 08:57:40 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BFvdr8010946 for ; Wed, 11 Jun 2008 08:57:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BFvafO014168 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 16:57:39 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00C0X300XL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:57:36 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B005V72ZZGY60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:57:35 -0600 (MDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5BFuD3I025416 for ; Wed, 11 Jun 2008 15:57:34 +0000 (GMT) Received: from mms25es.mms.us.syntegra.com ([150.143.232.90] [150.143.232.90]) by relay22i.sun.com with ESMTP id BT-MMP-916967 for PSARC-ext@sun.com; Wed, 11 Jun 2008 15:57:34 +0000 (Z) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54]) by mms25es.mms.us.syntegra.com with ESMTP id BT-MMP-27528678 for PSARC-ext@sun.com; Wed, 11 Jun 2008 15:57:34 +0000 (Z) Received: from yw-out-1718.google.com ([74.125.46.158] [74.125.46.158]) by relay23i.sun.com with ESMTP id BT-MMP-34158994 for PSARC-ext@sun.com; Wed, 11 Jun 2008 15:57:34 +0000 (Z) Received: by yw-out-1718.google.com with SMTP id 9so1849293ywk.68 for ; Wed, 11 Jun 2008 08:56:44 -0700 (PDT) Received: by 10.114.74.1 with SMTP id w1mr6734874waa.229.1213199803751; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) Received: by 10.114.131.13 with HTTP; Wed, 11 Jun 2008 08:56:43 -0700 (PDT) Date: Wed, 11 Jun 2008 10:56:43 -0500 From: Shawn Walker Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484FF4E3.6020105@Sun.Com> Sender: binarycrusader@gmail.com To: John Plocher Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=ec1SLJFtzzLiKT4sl3poPPunUYY98AUPnVeexBmvUYA=; b=vhViQari1iFEK7qoVBFO8MKVslY1SSs5SPhaLShfLO4nzxf4mzOgN0me+iXI1kyydm I8eb2ur3RecmkACjOUfPoZ8g52dxrUxRjuP+jmJYyJpQQyT4TSS1eFx3puM1Lxq22ehY D3xxvOjsguxfNjciDknj7XqYjV7dpFkV95qlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=iGVZ29bAZSmIqWerSp1I8G0Xu4aLY32s7NbHx/OUO84vc9t3YKZWvRmGya5s1BTWTP HgaPR4d3impVmjJdDBJgEsi4WxzSGWBzLnapbtQUOzEot0tvVEQHxielMM7R57m24WRS rRYMr5qo4mvXTRAUEwiwJYOoA+5Ek8Ol8HXm0= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: 64ad5959d7fc8f2c X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <484feb9d.YHM+iMEOHMiv6Wej%Joerg.Schilling@fokus.fraunhofer.de> <484FF0F6.1090307@sun.com> <484FF4E3.6020105@Sun.Com> Status: RO Content-Length: 714 2008/6/11 John Plocher : > Garrett D'Amore wrote: >> I also remain unfond of the approach of turning a bunch of key programs >> in /usr/bin into isaexec() links. While the isaexec() approach was not >> unreasonable for a few utilities that aren't run frequently like >> prtconf, I don't think the solution scales well. > > > Maybe there is an opportunity to leverage IPS here - have it install the > correct binaries from the repo (32, 64, x64, SPARC, Power, ARM...) based > on the isaexec-abilities of the target platform. > > (i.e., don't do isaexec() at runtime, do it at install time :-) I can already hear the complaints from people using nfs mounted binaries... :-) -- Shawn Walker From Nicolas.Williams@sun.com Wed Jun 11 08:58:50 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BFwn7r011152 for ; Wed, 11 Jun 2008 08:58:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BFwYSl014546; Wed, 11 Jun 2008 16:58:47 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B0070X31Y3900@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Jun 2008 08:58:46 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B0025B31WBYB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Jun 2008 08:58:45 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5BFweNq012750; Wed, 11 Jun 2008 10:58:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5BFwe0t012749; Wed, 11 Jun 2008 10:58:40 -0500 (CDT) Date: Wed, 11 Jun 2008 10:58:40 -0500 From: Nicolas Williams Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484EF55E.9090301@sun.com> To: "Garrett D'Amore" Cc: Roland Mainz , PSARC-ext@sun.com, John.Plocher@sun.com Mail-followup-to: Garrett D'Amore , Roland Mainz , PSARC-ext@sun.com, John.Plocher@sun.com Message-id: <20080611155839.GF2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 526 On Tue, Jun 10, 2008 at 02:42:54PM -0700, Garrett D'Amore wrote: > PS: Roland, please take my advice and take the time to do things "the > right way", which includes a complete ARC review of the 64-bit problems > you're trying to solve. Attempting to do an end-run around ARC with a > bunch of little cases to avoid providing the full picture is unlikely to > be well received. I don't think Roland was trying to do an end-run around anything. I think Roland didn't see that he was stepping into a minefield. Nico -- From Nicolas.Williams@sun.com Wed Jun 11 09:00:52 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BG0qgm011263 for ; Wed, 11 Jun 2008 09:00:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5BG0oAR022607; Wed, 11 Jun 2008 09:00:52 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00D0B35F7A00@brm-avmta-1.central.sun.com>; Wed, 11 Jun 2008 10:00:51 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B005ZU35BGV60@brm-avmta-1.central.sun.com>; Wed, 11 Jun 2008 10:00:47 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5BG0kPb012757; Wed, 11 Jun 2008 11:00:46 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5BG0jQ2012756; Wed, 11 Jun 2008 11:00:45 -0500 (CDT) Date: Wed, 11 Jun 2008 11:00:45 -0500 From: Nicolas Williams Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484FF4E3.6020105@Sun.Com> To: John Plocher Cc: "Garrett D'Amore" , Joerg Schilling , roland.mainz@nrubsig.org, PSARC-ext@sun.com Mail-followup-to: John Plocher , Garrett D'Amore , Joerg Schilling , roland.mainz@nrubsig.org, PSARC-ext@sun.com Message-id: <20080611160045.GG2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <484feb9d.YHM+iMEOHMiv6Wej%Joerg.Schilling@fokus.fraunhofer.de> <484FF0F6.1090307@sun.com> <484FF4E3.6020105@Sun.Com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 772 On Wed, Jun 11, 2008 at 08:53:07AM -0700, John Plocher wrote: > Garrett D'Amore wrote: > >I also remain unfond of the approach of turning a bunch of key programs > >in /usr/bin into isaexec() links. While the isaexec() approach was not > >unreasonable for a few utilities that aren't run frequently like > >prtconf, I don't think the solution scales well. > > Maybe there is an opportunity to leverage IPS here - have it install the > correct binaries from the repo (32, 64, x64, SPARC, Power, ARM...) based > on the isaexec-abilities of the target platform. > > (i.e., don't do isaexec() at runtime, do it at install time :-) Well, that would mean having x86/64 installs that can only boot in one of 32-bit or 64-bit modes, but not both. I personally don't mind. From gdamore@Sun.COM Wed Jun 11 09:13:29 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BGDSQU012194 for ; Wed, 11 Jun 2008 09:13:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BGDOvp022143 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 17:13:28 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B008113QFV200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:13:27 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B002933QEC1C0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:13:26 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BGDQ4B028709 for ; Wed, 11 Jun 2008 09:13:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B0070135UNT00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:13:26 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B00K373QELEH0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:13:26 -0700 (PDT) Date: Wed, 11 Jun 2008 09:12:30 -0700 From: "Garrett D'Amore" Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484FF4E3.6020105@Sun.Com> Sender: Garrett.Damore@Sun.COM To: John Plocher Cc: Joerg Schilling , roland.mainz@nrubsig.org, PSARC-ext@Sun.COM Message-id: <484FF96E.2040907@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <484feb9d.YHM+iMEOHMiv6Wej%Joerg.Schilling@fokus.fraunhofer.de> <484FF0F6.1090307@sun.com> <484FF4E3.6020105@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 751 John Plocher wrote: > Garrett D'Amore wrote: >> I also remain unfond of the approach of turning a bunch of key >> programs in /usr/bin into isaexec() links. While the isaexec() >> approach was not unreasonable for a few utilities that aren't run >> frequently like prtconf, I don't think the solution scales well. > > > Maybe there is an opportunity to leverage IPS here - have it install the > correct binaries from the repo (32, 64, x64, SPARC, Power, ARM...) based > on the isaexec-abilities of the target platform. > > (i.e., don't do isaexec() at runtime, do it at install time :-) An interesting idea. Except that we allow x64 systems to be booted in either 32- or 64- bit mode on the same root filesystem. -- Garrett > > -John > From Andrew.Gabriel@sun.com Wed Jun 11 09:16:35 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BGGYjf012308 for ; Wed, 11 Jun 2008 09:16:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BGGFLA023758 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 17:16:33 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B0080B3VJQX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:16:31 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B007FN3VHMZ30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:16:30 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BGGTXn025217 for ; Wed, 11 Jun 2008 16:16:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00A012AEYU00@fe-emea-09.sun.com> (original mail from Andrew.Gabriel@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 17:16:29 +0100 (BST) Received: from [192.9.200.17] ([81.187.162.106]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B005YQ3V3WP30@fe-emea-09.sun.com>; Wed, 11 Jun 2008 17:16:16 +0100 (BST) Date: Wed, 11 Jun 2008 17:16:20 +0100 From: Andrew Gabriel Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit[PSARC/2008/351SelfReview] In-reply-to: <484ED86D.509@sun.com> Sender: Andrew.Gabriel@sun.com To: Joseph Kowalski Cc: John Plocher , "Garrett D'Amore" , Roland Mainz , PSARC-ext@sun.com Message-id: <484FFA54.4070303@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ED86D.509@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) Status: RO Content-Length: 1623 Joseph Kowalski wrote: > John Plocher wrote: >> [Roland and I are bouncing a proposal back and forth...] >> >> Garrett D'Amore wrote: >>> 4) analysis of big-picture performance issues, if any (does 64-bit >>> run faster, or slower? maybe run a some test of boot time analysis.) >> >> IIRC, the SPARC impact was "doesn't run faster" combined with >> "takes more disk space", rather than "runs significantly slower". > > +1 > > ARC review is only to cover speed and size issues when they are large > enough to have some architectual impact. In my estimation, these don't > qualify. Who decides what's an acceptable performance drop in Solaris sparc? What would be your boundary at which speed becomes an issue? When I first measured the hit on 64 bit sparc binaries for one of my own CPU intensive (integer) applications some years back, 64 bit was 14% slower than a 32 bit build. Having just repeated this test using Studio 12 compilers, its down to 7% slower now. This isn't a scientific test, and needs measuring more accurately than I can at home on one system, and on different types of sparc we have around today. When I asked (again, many years ago) why we ship a 64 bit ls(1) but don't use it (i.e. it's not isaexec'ed), the answer I got was that this did nasty things to one of our performance metrics. (Not clear to me if that was due to the 64 bit ls(1), or the isaexec indirection). So I think ARC needs to know that the performance hit is below whatever level it (or someone) decides is the largest acceptable hit. Some of that sounds like a decision that needs Marketing input. -- Andrew From John.Plocher@sun.com Wed Jun 11 09:21:02 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BGL1Zb012601 for ; Wed, 11 Jun 2008 09:21:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BGKv6B026399 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 17:21:00 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00E1F430HD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 10:21:00 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B0056N42ZGX90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 10:20:59 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BGKxnm010140 for ; Wed, 11 Jun 2008 09:20:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B0020112W4Y00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:20:59 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B006B842T6WH0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 09:20:53 -0700 (PDT) Date: Wed, 11 Jun 2008 09:20:52 -0700 From: John Plocher Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484FF96E.2040907@sun.com> Sender: John.Plocher@sun.com To: "Garrett D'Amore" Cc: Joerg Schilling , roland.mainz@nrubsig.org, PSARC-ext@sun.com Message-id: <484FFB64.7070600@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <484feb9d.YHM+iMEOHMiv6Wej%Joerg.Schilling@fokus.fraunhofer.de> <484FF0F6.1090307@sun.com> <484FF4E3.6020105@Sun.Com> <484FF96E.2040907@sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 645 Garrett D'Amore wrote: > An interesting idea. Except that we allow x64 systems to be booted in > either 32- or 64- bit mode on the same root filesystem. As I said - "maybe" I could see an installer choice of Do you want to install a [pick one: 32-, 64- or 32+64-] bit bootable system? I don't believe isaexec() is a significant performance bottleneck for most of what we are talking about here. Yes, it is an extra exec, no it is not the most expensive thing the user is doing :-) Lets not do premature optimizations here - they might not really matter. Lets drop this thread until Roland has a spec for us to chew on... -John From bart.smaalders@Sun.COM Wed Jun 11 10:40:14 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BHeDW5016458 for ; Wed, 11 Jun 2008 10:40:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5BHe88Y027320; Thu, 12 Jun 2008 01:40:11 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00H0V7QY9700@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Jun 2008 10:40:10 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00DAG7QXI390@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Jun 2008 10:40:09 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m5BHe9CK021790; Wed, 11 Jun 2008 17:40:09 +0000 (GMT) Date: Wed, 11 Jun 2008 10:40:09 -0700 From: Bart Smaalders Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484FF4E3.6020105@Sun.Com> To: John Plocher Cc: "Garrett D'Amore" , Joerg Schilling , roland.mainz@nrubsig.org, PSARC-ext@Sun.COM Message-id: <48500DF9.8000603@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <484feb9d.YHM+iMEOHMiv6Wej%Joerg.Schilling@fokus.fraunhofer.de> <484FF0F6.1090307@sun.com> <484FF4E3.6020105@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 825 John Plocher wrote: > Garrett D'Amore wrote: >> I also remain unfond of the approach of turning a bunch of key >> programs in /usr/bin into isaexec() links. While the isaexec() >> approach was not unreasonable for a few utilities that aren't run >> frequently like prtconf, I don't think the solution scales well. > > > Maybe there is an opportunity to leverage IPS here - have it install the > correct binaries from the repo (32, 64, x64, SPARC, Power, ARM...) based > on the isaexec-abilities of the target platform. I still prefer my boot time approach - root image is still portable, just like it's portable wrt processor features today. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From gdamore@sun.com Wed Jun 11 10:42:28 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BHgRnU016731 for ; Wed, 11 Jun 2008 10:42:28 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BHgO59002207 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 18:42:26 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00H057UOF200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 10:42:24 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00DRQ7UOI5C0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 10:42:24 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BHgOS0021899 for ; Wed, 11 Jun 2008 10:42:24 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B003017G53H00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 10:42:24 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B003P37UH1R40@fe-sfbay-09.sun.com>; Wed, 11 Jun 2008 10:42:17 -0700 (PDT) Date: Wed, 11 Jun 2008 10:41:21 -0700 From: "Garrett D'Amore" Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <48500DF9.8000603@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: John Plocher , Joerg Schilling , roland.mainz@nrubsig.org, PSARC-ext@sun.com Message-id: <48500E41.1080203@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <484feb9d.YHM+iMEOHMiv6Wej%Joerg.Schilling@fokus.fraunhofer.de> <484FF0F6.1090307@sun.com> <484FF4E3.6020105@Sun.Com> <48500DF9.8000603@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 835 Bart Smaalders wrote: > John Plocher wrote: >> Garrett D'Amore wrote: >>> I also remain unfond of the approach of turning a bunch of key >>> programs in /usr/bin into isaexec() links. While the isaexec() >>> approach was not unreasonable for a few utilities that aren't run >>> frequently like prtconf, I don't think the solution scales well. >> >> >> Maybe there is an opportunity to leverage IPS here - have it install the >> correct binaries from the repo (32, 64, x64, SPARC, Power, ARM...) based >> on the isaexec-abilities of the target platform. > > I still prefer my boot time approach - root image is still portable, > just like > it's portable wrt processor features today. Me too. Bart, I'm willing to help out here to make something like this work out. (I am somewhat constrained.) -- Garrett > > - Bart > > From Darren.Reed@sun.com Wed Jun 11 11:10:19 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BIAJu5019392 for ; Wed, 11 Jun 2008 11:10:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5BIAI5J021256 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 11:10:19 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00D199561Q00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 11:10:18 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00CZC94TRI10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 11:10:17 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5BIARGK025053 for ; Wed, 11 Jun 2008 18:10:27 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K2B00F0192MTA00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 02:09:43 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K2B007JM945XJ2H@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 12 Jun 2008 02:09:43 +0800 (SGT) Date: Wed, 11 Jun 2008 11:10:03 -0700 From: Darren Reed Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <484EF55E.9090301@sun.com> Sender: Darren.Reed@sun.com To: "Garrett D'Amore" Cc: Roland Mainz , PSARC-ext@sun.com, John.Plocher@sun.com Message-id: <485014FB.2080202@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 492 FWIW, I think we're approaching the time when we are going to need to start thinking about transitioning time_t to being uint64_t - even for 32bit platforms (as a point of interest, earlier this year we went past the point in time where a 32bit time_t can hold the start and end dates of a 30 year mortgage.) Currently we have it as 'long' (in ), so we get 32bit or 64bit depending on the CPU architecture. The fallout of that should be things like stat64(2), etc... Darren From sacadmin Wed Jun 11 11:14:10 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BIEAt1019964 for ; Wed, 11 Jun 2008 11:14:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5BIE8Gq022392 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Wed, 11 Jun 2008 11:14:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00D019BL7A00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@Sun.COM); Wed, 11 Jun 2008 11:14:09 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00CQE9BLRI20@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@Sun.COM); Wed, 11 Jun 2008 11:14:09 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5BIE9ff022489 for ; Wed, 11 Jun 2008 18:14:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00E018QCFX00@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) for psarc@Sun.COM (ORCPT psarc@Sun.COM); Wed, 11 Jun 2008 12:14:08 -0600 (MDT) Received: from [129.145.154.55] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B00GD59BDAUA0@mail-amer.sun.com> for psarc@Sun.COM (ORCPT psarc@Sun.COM); Wed, 11 Jun 2008 12:14:02 -0600 (MDT) Date: Wed, 11 Jun 2008 11:14:01 -0700 From: Aarti Pai Subject: PSARC Meeting Minutes - 06/11/2008 - [2008/351] Sender: Aarti.Pai@sun.com To: psarc@sun.com Cc: Roland Mainz , John Plocher Reply-to: Aarti.Pai@sun.com Message-id: <485015E9.70406@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 325 Minutes/Audio for PSARC 06/11/2008 are now available: - Open Arc Business: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080611.arcbiz.open Audio: http://sac.sfbay/Archives/Minutes/PSARC/2008/20080611.arcbiz.open.mp3 Please contact me directly if you require any corrections/modifications to these minutes. Aarti From gdamore@sun.com Wed Jun 11 11:39:52 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BIdp5R022551 for ; Wed, 11 Jun 2008 11:39:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BIdofP028270 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 19:39:50 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00E05AIDBV00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 11:39:49 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00CBEAIDRGA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 11:39:49 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BIdngC029939 for ; Wed, 11 Jun 2008 11:39:49 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00L01ADCKB00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 11:39:49 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B00DOAAI9P4G0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 11:39:46 -0700 (PDT) Date: Wed, 11 Jun 2008 11:38:48 -0700 From: "Garrett D'Amore" Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <485014FB.2080202@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: Roland Mainz , PSARC-ext@sun.com, John.Plocher@sun.com Message-id: <48501BB8.6050904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <485014FB.2080202@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 927 Darren Reed wrote: > FWIW, I think we're approaching the time when we are going to need to > start thinking about transitioning time_t to being uint64_t - even for > 32bit platforms (as a point of interest, earlier this year we went past > the point in time where a 32bit time_t can hold the start and end dates > of a 30 year mortgage.) > > Currently we have it as 'long' (in ), so we get 32bit > or 64bit depending on the CPU architecture. > > The fallout of that should be things like stat64(2), etc... > > Darren > I agree whole heartedly. I think the "fix" presented for touch, which is to deliver 64-bit only, is incomplete, since it doesn't help 32-bit kernels which are still interesting. This may be a bigger project to fix, but I think at some point we're going to have to do it, because I don't think we can wait the 10 years it will take for us to finally EOF 32-bit platforms. -- Garrett From Andrew.Gabriel@sun.com Wed Jun 11 12:16:45 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BJGiwa025495 for ; Wed, 11 Jun 2008 12:16:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5BJGiJ0032089 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 13:16:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00403C7WA200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 12:16:44 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00JG6C7T3S90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 12:16:41 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BJGeT2014942 for ; Wed, 11 Jun 2008 19:16:40 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00A01C5UGP00@fe-emea-09.sun.com> (original mail from Andrew.Gabriel@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 20:16:40 +0100 (BST) Received: from [192.9.200.17] ([81.187.162.106]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B00HTUC7SH960@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 11 Jun 2008 20:16:40 +0100 (BST) Date: Wed, 11 Jun 2008 20:16:46 +0100 From: Andrew Gabriel Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <485014FB.2080202@Sun.COM> Sender: Andrew.Gabriel@sun.com To: Darren Reed Cc: "Garrett D'Amore" , Roland Mainz , PSARC-ext@sun.com, John.Plocher@sun.com Message-id: <4850249E.9000006@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <485014FB.2080202@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080519) Status: RO Content-Length: 824 Darren Reed wrote: > FWIW, I think we're approaching the time when we are going to need to > start thinking about transitioning time_t to being uint64_t - even for > 32bit platforms (as a point of interest, earlier this year we went past > the point in time where a 32bit time_t can hold the start and end dates > of a 30 year mortgage.) No banking software I've been exposed to uses unix/C types for this kind of thing. (That would be easier and very much less error prone than what they do actually use;-) > Currently we have it as 'long' (in ), so we get 32bit > or 64bit depending on the CPU architecture. > > The fallout of that should be things like stat64(2), etc... stat64(2) already exists -- you get it with largefile compiles. However, I don't think the time fields are 64 bit. -- Andrew From Joerg.Schilling@fokus.fraunhofer.de Wed Jun 11 14:46:01 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BLjvUd005537 for ; Wed, 11 Jun 2008 14:46:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5BLjsfp020227; Wed, 11 Jun 2008 14:45:54 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00K01J4INJ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Jun 2008 14:45:54 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00D09J4HJE40@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Jun 2008 14:45:54 -0700 (PDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5BLgZCa026043; Wed, 11 Jun 2008 21:45:53 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay12i.sun.com with ESMTP id BT-MMP-109924; Wed, 11 Jun 2008 21:45:53 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-35758758; Wed, 11 Jun 2008 21:45:52 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay1i.sun.com with ESMTP id BT-MMP-1212707; Wed, 11 Jun 2008 21:45:52 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw27] (8.14.2+/8.14.2) with ESMTP id m5BLeVCc020066; Wed, 11 Jun 2008 23:40:31 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5BLeVtJ020062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jun 2008 23:40:31 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5BLeUtN023041; Wed, 11 Jun 2008 23:40:31 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 23:40:30 +0200 Date: Wed, 11 Jun 2008 23:40:30 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <4850249E.9000006@sun.com> To: Darren.Reed@sun.com, Andrew.Gabriel@sun.com Cc: PSARC-ext@sun.com, John.Plocher@sun.com, gdamore@sun.com Message-id: <4850464e.6wkx25DWU21wukAb%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.360sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <485014FB.2080202@Sun.COM> <4850249E.9000006@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 11 Jun 2008 21:40:30.0998 (UTC) FILETIME=[C57BA360:01C8CC0B] Status: RO Content-Length: 505 Andrew Gabriel wrote: > stat64(2) already exists -- you get it with largefile compiles. However, > I don't think the time fields are 64 bit. They are not. This is the problem. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From gdamore@sun.com Wed Jun 11 15:30:05 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BMU5VD009269 for ; Wed, 11 Jun 2008 15:30:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5BMU35w016380 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 16:30:05 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B0020NL64GJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:30:04 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00D2KL5YJ760@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:30:03 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BMTwuT021809 for ; Wed, 11 Jun 2008 15:29:58 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00H01KZX8I00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:29:58 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B00FAVL5KILF0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:29:45 -0700 (PDT) Date: Wed, 11 Jun 2008 15:28:47 -0700 From: "Garrett D'Amore" Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <4850464e.6wkx25DWU21wukAb%Joerg.Schilling@fokus.fraunhofer.de> Sender: Garrett.Damore@sun.com To: Joerg Schilling Cc: Darren.Reed@sun.com, Andrew.Gabriel@sun.com, PSARC-ext@sun.com, John.Plocher@sun.com Message-id: <4850519F.1070702@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <485014FB.2080202@Sun.COM> <4850249E.9000006@sun.com> <4850464e.6wkx25DWU21wukAb%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 726 Joerg Schilling wrote: > Andrew Gabriel wrote: > > >> stat64(2) already exists -- you get it with largefile compiles. However, >> I don't think the time fields are 64 bit. >> > > They are not. This is the problem. > > Jörg > > I think its time we invented a new version of stat, utimes, etc. that used 64-bit time_t's, even on 32-bit kernels. Some new compilation flags (-DTIME64 ?) could use #pragma's to rename the symbols for "new" programs, which could be then used for compiling programs in ON. I don't have the time to invest in this project myself, but I'd be happy to be an ARC sponsor for such work if someone else decided they wanted to do this work. -- Garrett From Joerg.Schilling@fokus.fraunhofer.de Wed Jun 11 15:41:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BMfK2R010376 for ; Wed, 11 Jun 2008 15:41:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BMf9tf004070; Wed, 11 Jun 2008 23:41:16 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00K01LOR7X00@brm-avmta-1.central.sun.com>; Wed, 11 Jun 2008 16:41:15 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B0002ULOQIXD0@brm-avmta-1.central.sun.com>; Wed, 11 Jun 2008 16:41:14 -0600 (MDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BMfBBd028534; Wed, 11 Jun 2008 22:41:14 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay44i.sun.com with ESMTP id BT-MMP-517219; Wed, 11 Jun 2008 22:41:11 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-27327539; Wed, 11 Jun 2008 22:41:11 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay4i.sun.com with ESMTP id BT-MMP-17722223; Wed, 11 Jun 2008 22:40:10 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw22] (8.14.2+/8.14.2) with ESMTP id m5BMYoCY021348; Thu, 12 Jun 2008 00:34:50 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5BMYnqp021344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2008 00:34:49 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5BMYnXU024633; Thu, 12 Jun 2008 00:34:49 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jun 2008 00:34:49 +0200 Date: Thu, 12 Jun 2008 00:34:49 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <4850519F.1070702@sun.com> To: gdamore@sun.com Cc: PSARC-ext@sun.com, John.Plocher@sun.com, Darren.Reed@sun.com, Andrew.Gabriel@sun.com Message-id: <48505309.tR2212FdKIqN1X/5%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.215sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <485014FB.2080202@Sun.COM> <4850249E.9000006@sun.com> <4850464e.6wkx25DWU21wukAb%Joerg.Schilling@fokus.fraunhofer.de> <4850519F.1070702@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 11 Jun 2008 22:34:49.0488 (UTC) FILETIME=[5BB1C100:01C8CC13] Status: RO Content-Length: 947 "Garrett D'Amore" wrote: > >> stat64(2) already exists -- you get it with largefile compiles. However, > >> I don't think the time fields are 64 bit. > >> > > > > They are not. This is the problem. > > > > Jörg > I think its time we invented a new version of stat, utimes, etc. that > used 64-bit time_t's, even on 32-bit kernels. Some new compilation > flags (-DTIME64 ?) could use #pragma's to rename the symbols for "new" > programs, which could be then used for compiling programs in ON. If you like this to be independent of largefile compilation, you would need to introduce two new interfaces for stat(2). Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Alan.Coopersmith@Sun.COM Wed Jun 11 15:47:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BMlN1r010552 for ; Wed, 11 Jun 2008 15:47:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BMl9qx006431 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 23:47:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00105LYXY200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:47:21 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00FK6LYWAW90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:47:20 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BMlKj5000618 for ; Wed, 11 Jun 2008 15:47:20 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00101LF4JZ00@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:47:20 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B00B0WLYRQ420@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:47:16 -0700 (PDT) Date: Wed, 11 Jun 2008 15:47:15 -0700 From: Alan Coopersmith Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <48505309.tR2212FdKIqN1X/5%Joerg.Schilling@fokus.fraunhofer.de> Sender: Alan.Coopersmith@Sun.COM To: Joerg Schilling Cc: gdamore@Sun.COM, PSARC-ext@Sun.COM, John.Plocher@Sun.COM, Darren.Reed@Sun.COM, Andrew.Gabriel@Sun.COM Message-id: <485055F3.5010000@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <485014FB.2080202@Sun.COM> <4850249E.9000006@sun.com> <4850464e.6wkx25DWU21wukAb%Joerg.Schilling@fokus.fraunhofer.de> <4850519F.1070702@sun.com> <48505309.tR2212FdKIqN1X/5%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 986 Joerg Schilling wrote: > "Garrett D'Amore" wrote: > >>>> stat64(2) already exists -- you get it with largefile compiles. However, >>>> I don't think the time fields are 64 bit. >>>> >>> They are not. This is the problem. >>> >>> Jörg > > >> I think its time we invented a new version of stat, utimes, etc. that >> used 64-bit time_t's, even on 32-bit kernels. Some new compilation >> flags (-DTIME64 ?) could use #pragma's to rename the symbols for "new" >> programs, which could be then used for compiling programs in ON. > > If you like this to be independent of largefile compilation, you would need > to introduce two new interfaces for stat(2). And that's my concern - how many types are we going to retrofit in the 32-bit ABI, and what is the resulting combinatorial explosion of different type-combinations going to look like? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From gdamore@sun.com Wed Jun 11 15:53:27 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BMrQgF010852 for ; Wed, 11 Jun 2008 15:53:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BMrHYF008788 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 23:53:25 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B00207M8Z8500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:53:23 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00FO1M8ZAQB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:53:23 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BMrN9N001394 for ; Wed, 11 Jun 2008 15:53:23 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00201M4KR700@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:53:23 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B003DLM8VWQ80@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:53:19 -0700 (PDT) Date: Wed, 11 Jun 2008 15:52:22 -0700 From: "Garrett D'Amore" Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <48505309.tR2212FdKIqN1X/5%Joerg.Schilling@fokus.fraunhofer.de> Sender: Garrett.Damore@sun.com To: Joerg Schilling Cc: PSARC-ext@sun.com, John.Plocher@sun.com, Darren.Reed@sun.com, Andrew.Gabriel@sun.com Message-id: <48505726.1040008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <485014FB.2080202@Sun.COM> <4850249E.9000006@sun.com> <4850464e.6wkx25DWU21wukAb%Joerg.Schilling@fokus.fraunhofer.de> <4850519F.1070702@sun.com> <48505309.tR2212FdKIqN1X/5%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 922 Joerg Schilling wrote: > "Garrett D'Amore" wrote: > > >>>> stat64(2) already exists -- you get it with largefile compiles. However, >>>> I don't think the time fields are 64 bit. >>>> >>>> >>> They are not. This is the problem. >>> >>> Jörg >>> > > > >> I think its time we invented a new version of stat, utimes, etc. that >> used 64-bit time_t's, even on 32-bit kernels. Some new compilation >> flags (-DTIME64 ?) could use #pragma's to rename the symbols for "new" >> programs, which could be then used for compiling programs in ON. >> > > If you like this to be independent of largefile compilation, you would need > to introduce two new interfaces for stat(2). > No need to be independent of LARGEFILE. I am happy with the idea that this feature might also only be available for programs compiled with largefile support. -- Garrett > Jörg > > From gdamore@sun.com Wed Jun 11 15:55:54 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5BMtrKs011210 for ; Wed, 11 Jun 2008 15:55:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5BMtjax009720 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Jun 2008 23:55:52 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2B0050HMD2HP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:55:50 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2B00DI1MD2JE80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:55:50 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5BMtoN2001702 for ; Wed, 11 Jun 2008 15:55:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2B00301M9ZL800@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:55:50 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2B00BVLMCYQ450@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Jun 2008 15:55:46 -0700 (PDT) Date: Wed, 11 Jun 2008 15:54:49 -0700 From: "Garrett D'Amore" Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <485055F3.5010000@sun.com> Sender: Garrett.Damore@sun.com To: Alan Coopersmith Cc: Joerg Schilling , PSARC-ext@sun.com, John.Plocher@sun.com, Darren.Reed@sun.com, Andrew.Gabriel@sun.com Message-id: <485057B9.9010803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <485014FB.2080202@Sun.COM> <4850249E.9000006@sun.com> <4850464e.6wkx25DWU21wukAb%Joerg.Schilling@fokus.fraunhofer.de> <4850519F.1070702@sun.com> <48505309.tR2212FdKIqN1X/5%Joerg.Schilling@fokus.fraunhofer.de> <485055F3.5010000@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1423 Alan Coopersmith wrote: > Joerg Schilling wrote: > >> "Garrett D'Amore" wrote: >> >> >>>>> stat64(2) already exists -- you get it with largefile compiles. However, >>>>> I don't think the time fields are 64 bit. >>>>> >>>>> >>>> They are not. This is the problem. >>>> >>>> Jörg >>>> >> >>> I think its time we invented a new version of stat, utimes, etc. that >>> used 64-bit time_t's, even on 32-bit kernels. Some new compilation >>> flags (-DTIME64 ?) could use #pragma's to rename the symbols for "new" >>> programs, which could be then used for compiling programs in ON. >>> >> If you like this to be independent of largefile compilation, you would need >> to introduce two new interfaces for stat(2). >> > > And that's my concern - how many types are we going to retrofit in the > 32-bit ABI, and what is the resulting combinatorial explosion of different > type-combinations going to look like? > The matrix of supported options can be "sparse". We don't have to support small files with 64-bit times, for example. It does mean that the times used for system calls involving time_t need to be updated. There probably aren't that many. Driver-specific ioctls with time_t embedded in them can be converted on an as needed basis (hopefully there aren't that many driver-specific ioctls passing around time_ts.) -- Garrett From Joerg.Schilling@fokus.fraunhofer.de Thu Jun 12 01:59:07 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5C8x6Wg029648 for ; Thu, 12 Jun 2008 01:59:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5C8x2fm022911; Thu, 12 Jun 2008 02:59:04 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2C00515EAFL100@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 01:59:03 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2C001JFEAEHW70@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Jun 2008 01:59:03 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5C8x2OY020154; Thu, 12 Jun 2008 08:59:02 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-64181; Thu, 12 Jun 2008 08:59:02 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-27952110; Thu, 12 Jun 2008 08:59:00 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay4i.sun.com with ESMTP id BT-MMP-22539816; Thu, 12 Jun 2008 08:59:00 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw22] (8.14.2+/8.14.2) with ESMTP id m5C8sJJu002349; Thu, 12 Jun 2008 10:54:19 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5C8sJ3N002339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jun 2008 10:54:19 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5C8sJ5l027109; Thu, 12 Jun 2008 10:54:19 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jun 2008 10:54:19 +0200 Date: Thu, 12 Jun 2008 10:54:19 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Fixing "touch" to reset ancient/weired/far-future timestamps... / was: Re: Switch SPARC GNU coreutils+bash from 32 to64bit[PSARC/2008/351SelfReview] In-reply-to: <48501BB8.6050904@sun.com> To: gdamore@sun.com, darren.reed@sun.com Cc: PSARC-ext@sun.com, John.Plocher@sun.com Message-id: <4850e43b.VAYz7a3VcYyFW265%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 1.217sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200805301544.m4UFix3n026760@sac.sfbay.sun.com> <48404431.9010701@sun.com> <4843C3D1.8060203@Sun.COM> <484428A0.6010108@Sun.COM> <48442EA9.7020502@sun.com> <48443BC3.1010802@Sun.COM> <48445B37.C007CCFE@nrubsig.org> <4844604C.8070903@Sun.COM> <484CDA4A.A6F8F67C@nrubsig.org> <484D763E.1000404@sun.com> <484EAABB.7739612F@nrubsig.org> <484EB6C5.5000108@sun.com> <484EB9FB.78159F03@nrubsig.org> <484EBF1F.9040504@sun.com> <484ECA72.3000503@Sun.Com> <484ee206.i2m/f/1SR8oXsUW0%Joerg.Schilling@fokus.fraunhofer.de> <484EF261.7AE75ECE@nrubsig.org> <484EF55E.9090301@sun.com> <485014FB.2080202@Sun.COM> <48501BB8.6050904@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 12 Jun 2008 08:54:19.0226 (UTC) FILETIME=[E695ABA0:01C8CC69] Status: RO Content-Length: 760 "Garrett D'Amore" wrote: > I agree whole heartedly. I think the "fix" presented for touch, which > is to deliver 64-bit only, is incomplete, since it doesn't help 32-bit > kernels which are still interesting. I am not sure if this applies to all problems but many of the file time stamp problems are not visible on top of 32 bit kernels as the kernel already did truncate the range of the time stamp before the stat(2) call is applied. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From John.Plocher@sun.com Tue Jun 17 22:44:48 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5I5imMt020769 for ; Tue, 17 Jun 2008 22:44:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5I5imJL057122 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 17 Jun 2008 23:44:48 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2N00I039AOZE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Jun 2008 22:44:48 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2N00GG19AOXQ70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Jun 2008 22:44:48 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5I5imA8003998 for ; Tue, 17 Jun 2008 22:44:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2N00B0195Q5G00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Jun 2008 22:44:47 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2N00GD59ANHL60@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Jun 2008 22:44:47 -0700 (PDT) Date: Tue, 17 Jun 2008 22:44:47 -0700 From: John Plocher Subject: Status of PSARC/2008/351 (32/64-bit expectations case) Sender: John.Plocher@sun.com To: psarc-ext Message-id: <4858A0CF.5060603@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 466 There is a drafty opinion in the case dir that Joe, Glenn and Garrett have kindly looked at, but since Roland (the project team) has not yet provided feedback on either "the spec" or "the opinion", and I expect some changes/ additions based on his feedback, I am reluctant to push this case to a formal vote tomorrow. I will try to bring things to closure before COB Thursday so this can pop up on the ARC's radar screen in time for next week's meeting. -John From Darren.Moffat@sun.com Wed Jun 18 03:20:08 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5IAK8pk026288 for ; Wed, 18 Jun 2008 03:20:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5IAJx9h022157 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Jun 2008 04:20:07 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2N0023TM1IR300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jun 2008 03:20:06 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2N00INOM1H3850@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jun 2008 03:20:06 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5IAK4te010157 for ; Wed, 18 Jun 2008 10:20:04 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2N00A01LVX3S00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jun 2008 11:20:04 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2N00IGLM17GW90@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jun 2008 11:19:56 +0100 (BST) Date: Wed, 18 Jun 2008 11:19:55 +0100 From: Darren J Moffat Subject: Re: Status of PSARC/2008/351 (32/64-bit expectations case) In-reply-to: <4858A0CF.5060603@Sun.Com> Sender: Darren.Moffat@sun.com To: John Plocher Cc: psarc-ext Message-id: <4858E14B.6000402@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4858A0CF.5060603@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 1001 John Plocher wrote: > There is a drafty opinion in the case dir that Joe, Glenn and Garrett have > kindly looked at, but since Roland (the project team) has not yet provided > feedback on either "the spec" or "the opinion", and I expect some changes/ > additions based on his feedback, I am reluctant to push this case to a > formal > vote tomorrow. > > I will try to bring things to closure before COB Thursday so this can > pop up > on the ARC's radar screen in time for next week's meeting. "32-bit-only processor architectures obviously can not run 64-bit code, and should not install 64-bit anything." That is counter to the current architecture and I think unwise. There is no reason why an install done on a 32 bit kernel should not install 64 bit binaries. This would actually be a step backwards to where we were in Solaris 7. The issue is the word "install". Installation isn't IMO part of this case so I recommend just dropping that whole sentence. -- Darren J Moffat From gdamore@sun.com Wed Jun 18 06:58:41 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5IDwfCW000605 for ; Wed, 18 Jun 2008 06:58:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5IDweuq012220 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Jun 2008 06:58:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2N00C01W5SIT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jun 2008 07:58:40 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2N0083SW5RK140@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jun 2008 07:58:40 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5IDwdDC011105 for ; Wed, 18 Jun 2008 06:58:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2N00B01W210U00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jun 2008 06:58:39 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2N0000BW5Q2X40@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Jun 2008 06:58:38 -0700 (PDT) Date: Wed, 18 Jun 2008 06:57:13 -0700 From: "Garrett D'Amore" Subject: Re: Status of PSARC/2008/351 (32/64-bit expectations case) In-reply-to: <4858E14B.6000402@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: John Plocher , psarc-ext Message-id: <48591439.4020906@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4858A0CF.5060603@Sun.Com> <4858E14B.6000402@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1351 Darren J Moffat wrote: > John Plocher wrote: >> There is a drafty opinion in the case dir that Joe, Glenn and Garrett >> have >> kindly looked at, but since Roland (the project team) has not yet >> provided >> feedback on either "the spec" or "the opinion", and I expect some >> changes/ >> additions based on his feedback, I am reluctant to push this case to >> a formal >> vote tomorrow. >> >> I will try to bring things to closure before COB Thursday so this can >> pop up >> on the ARC's radar screen in time for next week's meeting. > > "32-bit-only processor architectures obviously can not run > 64-bit code, and should not install 64-bit anything." > > That is counter to the current architecture and I think unwise. There > is no reason why an install done on a 32 bit kernel should not install > 64 bit binaries. This would actually be a step backwards to where we > were in Solaris 7. Yes. But maybe the idea is that there could be some processor architecture (say ARM) that we wind up supporting where there is no definition for 64-bits. That's quite different from i386, where 64-bit support is conditional based upon the specific processor. > > The issue is the word "install". Installation isn't IMO part of this > case so I recommend just dropping that whole sentence. Probably a good idea. - Garrett From plocher@sac.sfbay.sun.com Thu Jun 19 18:16:46 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5K1GkQr013656 for ; Thu, 19 Jun 2008 18:16:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5K1Gk9f014850 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 19 Jun 2008 18:16:46 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2Q00K05M7XVM00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 19 Jun 2008 18:16:45 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2Q0043WM7XSFE0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 19 Jun 2008 18:16:45 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5K1GjSg035545 for ; Thu, 19 Jun 2008 18:16:45 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5K1GdIW013653 for ; Thu, 19 Jun 2008 18:16:45 -0700 (PDT) Received: (from plocher@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m5K1GdT8013652 for psarc-ext@sun.com; Thu, 19 Jun 2008 18:16:39 -0700 (PDT) Date: Thu, 19 Jun 2008 18:16:39 -0700 (PDT) From: John Plocher Subject: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit To: psarc-ext@sun.com Message-id: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 9930 Spec: http://www.opensolaris.org/os/community/arc/caselog/2008/351/proposal Draft Opinion (also below): http://www.opensolaris.org/os/community/arc/caselog/2008/351/opinion-draft-txt Notes: I will be out of electronic communication on vacation for the next 2 weeks This is a *draft* opinion intended to be used as context for a vote. It needs wordsmithing in several places, including the "not architectural" sections in section 4. Contributions of "better words" would be very much appreciated. I will catch up when (if?) I come back to civilization :-) -John ============= Draft Opinion ============= sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Switch SPARC GNU coreutils+bash from 32 to 64bit Submitted by: Roland Mainz File: PSARC/2008/351/opinion.ms Date: VOTE NEEDED Committee: Usual suspects: (John Plocher), Kais Bel- gaied, Mark Carlson, James D. Carlson, Gar- rett D'amore, Joseph Kowalski, Tim Marsland, Richard Matthews, Darren Moffat, Glenn Skinner, Bill Sommerfeld, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary There are emerging processor architectures where supporting *any* 32-bit userland is problematic or impossible. There is a class of "limitations/bugs" in many utilities related to the use of 32-bit data structures. This case sets 32/64 bit expectations going forward. When applying these guidelines, consider that "Everyone can, most should and nobody must" use them. New code developed specifically for Solaris or OpenSolaris certainly should be 64-bit clean. However, code imported from another ecosystem shouldn't face that requirement; there's no question that it's highly desirable, but such code may bring other benefits that outweigh any deficiencies that not being 64-bit clean might induce. 2. Decision & Precedence Information The project is approved as specified in reference [1]. Projects following this policy may be delivered in minor releases of any consolidation. This project sets precedent concerning 64-bit binaries. 3. Interfaces The project exports no interfaces. The project imports no interfaces. 4. Opinion The architecture here is simple - we need to be able to sup- port 64 bit-only systems. This implies that it is a bug to not be 64-bit clean. We also have 32-bit systems we need to support, so it is also a bug to not be 32-bit clean. It may be reasonable to hold up code "we write" to a higher standard than code that "we import from elsewhere", but, in the end, this is a C-Team rather than ARC issue: The ARC expects things to build correctly on both 32- and 64-bit processor architectures, and it is up to the C-Teams and/or Distro builders to choose how they will actually build things. Projects importing exteral software should consider trying to compile 64-bit - and file bugs upstream if found. 4.1. Where do 64-bit binaries make sense? 4.1.1. On 64-bit-only processor architectures that do not support 32-bit code, we must produce 64-bit code. When porting OpenSolaris to a totally new ISA, perhaps one could skip the effort to build a 32-bit support, and *only* do 64-bit, because at that point, there might not be any need to support a legacy 32-bit environment. 4.1.2. On 64-bit processor architectures that support run- ning 32-bit code, it is acceptable to have a mix of 32- and 64- bit programs. The decision to provide 64-bit-only code, to use something like isaexec() to provide both 32- and 64-bit code, or to remain with 32-bit only code should be made on a case by case basis. On x86/x64 systems, we have historically shipped an OS that had the ability to boot and run the same OS image on both 32- and 64-bit capable hardware. This opinion does nothing to change that status quo. Converting everything to 64-bit isn't a mandate at this time. 64-bit binaries provide certain advantages in avoid- ing capacity limitations. These advantages come at a cost that's becoming less burdensome over time as system capabil- ities (speed, memory size, file system space) increase. The trade-offs are shifting to make 64-bit binaries enough more attractive that self-review may suffice for many cases that propose to replace 32-bit binaries with corresponding 64-bit binaries. But we are not at the point where we can support blanket "do it all" or "no conversions need review" asser- tions. 4.1.3. 32-bit-only processor architectures obviously can not run 64-bit code. This implies that the build system still needs to be able to produce 32-bit code, so things need to remain "32-bit clean" as well. As with the 64-bit note above, the economic imperitives may change such that 32-bit-only systems are no longer "interesting" - at which point this guidance will need to be updated. For now, deviations (either way) need justifica- tion and associated review. 4.2. The "case by case" analysis mentioned above needs to address the following issues: 4.2.1. Does the code have 32-bit limits? If so, are those limits addressable using mechanisms other than 64-bit conversion? If so, consider using those mechanisms to provide value on 32-bit platforms independent from a decision to convert to 64-bit. (i.e., large file awareness, instruction set, ...) 4.2.2. Is the code 64-bit clean? If not (due to source code design and implementation prob- lems), bugs should filed against it. 4.2.3. Are there other utilities that should all be con- verted together? Consider both within families (i.e., all the GNU utils) and across (all the various flavors of grep...) 4.3. Non-architectural issues 4.3.1. Bitness parity between utilities in a "family" or across the platforms supported by a release There was some discussion about whether we needed to convert complete groupings of utilities as subprojects, either because there was value in having like things be the same bitness or because having them be different might be a call generator (if gnugrep behaves differently on large files than does /usr/bin/grep...). In the end, the Committee did not see this "family grouping" as an ARC requirement. There was also discussion about bitness-related functional- ity differences across platforms - a 32-bit binary on x86 behaving differently than the same command on 64-bit SPARC, for example. This difference was seen by the Committee as being a natural differentiation between hardware platforms with different capabilities, and not something that needed ARC intervention. 4.3.2. Who gets to decide what changes get accepted into "OpenSolaris", especially ones that affect the way the "OpenSolaris Binaries" are built? One member asserted "The real issue is that this isn't a change for you, or even the community to decide. Where did you suddenly become "product czar" for Sun's Solaris product? I expect this self-review -> fast-track will simply disappear. Its a product decision. I think it was silly that you even suggested it. (Yea, I know the sources should be on the other side of firewall and probably there should be a community con- trolled distro, but that isn't the case.) 4.3.3. How to ensure that bitness regressions don't happen The project team was concerned that there might be source code regressions without some mechanism to ensure that the 64-bit clean work was used and tested. The Committee referred the project team to the C-Team to work out appropriate automation and testing policy and mechanisms to guard against such things. 5. Minority Opinion(s) None 6. Advisory Information 6.1. Limitations of isaecec() Some members raised concerns that we may be missing out on performance and features by not providing 64-bit versions of programs by default, on those platforms which can run both 32- and 64-bit programs (such as amd64). A good example of this is grep, where a 64-bit grep can support processing of larger files, and on amd64 may out perform the i386 version. The current solution to supporting run-time selection of the ISA for the binary, isaexec, has some known performance lim- itations, and may not scale well, particularly for programs that are executed frequently. Thus, the PAC is advised to initiate a project to find an alternative to isaexec that offers run time ISA selection, without less performance impact than isaexec, and to make wider use of that alterna- tive to provide 64-bit feature parity between both platforms that are only 64-bit kernel capable (e.g. SPARC) and dual- mode platforms running in 64-bit mode (e.g. amd64). 6.2. 64-bit time_t on 32-bit systems Some members also raised concerns about a class of bugs related to the fact that 32-bit kernels, and 32-bit programs as a result, are only able to keep time in 32-bit sized integers. This can create problems, and bug disparities between 32 and 64-bit versions of programs such as touch(1). The PAC is advised to initiate a project to provide 64-bit timekeeping and associated system calls (such as lstat64_2(), utimes64(), or such) to 32-bit kernels and 32- bit userland. 7. Appendices 7.1. Appendix A: Technical Changes Required None 7.2. Appendix B: Technical Changes Advised None 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2008/351. 3. Proposal File: proposal Mail log File: mail PSARC/2008/351 Copyright 2008 Sun Microsystems From jek3@sun.com Thu Jun 19 19:40:46 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5K2ejY5014537 for ; Thu, 19 Jun 2008 19:40:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5K2eaLY018011 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 20 Jun 2008 10:40:44 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2Q00501Q3TF000@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 19 Jun 2008 20:40:41 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2Q003I0Q3T3J80@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 19 Jun 2008 20:40:41 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5K2ec2O820362; Thu, 19 Jun 2008 19:40:38 -0700 (PDT) Date: Thu, 19 Jun 2008 16:43:39 -1000 From: Joseph Kowalski Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> To: John Plocher Cc: psarc-ext@sun.com Message-id: <485B195B.3030400@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 2435 > 4.3.2. Who gets to decide what changes get accepted into > "OpenSolaris", especially ones that affect the way the > "OpenSolaris Binaries" are built? > > One member asserted > "The real issue is that this isn't a change for you, or > even the community to decide. Where did you suddenly > become "product czar" for Sun's Solaris product? I > expect this self-review -> fast-track will simply > disappear. Its a product decision. I think it was > silly that you even suggested it. > > (Yea, I know the sources should be on the other side of > firewall and probably there should be a community con- > trolled distro, but that isn't the case.) > Interesting. First, I'm the "one member". I'll stand by the assertion. However, I'm more than a bit miffed that this quote is from an e-mail I sent to the submitter: Roland Mainz. There were no other recipients. None, zero, nadda, Its also taken from a fairly long mail trail leaving out the context. Of course, I could provide the broader context, but to do so would violate my sense of ethics. Perhaps Roland would care to provide the entire mail message? I would welcome any comments, private or public, from this audience as how they react to private conversations ending up into publicly distributed documents, particularly indexed, archived documents. Perhaps some view the unspecific reference of "one member" as making this OK. I don't. There are currently on the order of 8 members and there are 3 (or less) who publicly commented on this issue. Its rather specific. I have no issue with my quotation being shared with the opinion author - John Plocher (hopefully shown the whole e-mail message). However, I wonder about his judgment in including this in the opinion; it seems that a long standing ARC member (and facilitator) should know better. Isn't John the individual who censored Joerg's posting and authored a "Guide to ARC e-mail Etiquette?". John, how did this get past you? Its also interesting that this is from section 4 of the opinion. That's supposed to illuminate the issues which concerned the ARC and their resulting beliefs. This just highlights "one members assertion" without providing the resulting conclusion by the full membership. Perhaps this is because this issue has still not been resolved? - jek3 (that's joseph.kowalski@sun.com) From John.Plocher@sun.com Thu Jun 19 22:28:03 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5K5S3Et017062 for ; Thu, 19 Jun 2008 22:28:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5K5S3Oa017346 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 19 Jun 2008 22:28:03 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2Q00H1FXUQIO00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 19 Jun 2008 23:28:02 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2Q007GAXUP4LB0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 19 Jun 2008 23:28:01 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5K5S0A9010060 for ; Thu, 19 Jun 2008 22:28:00 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2Q00K01XNPQ100@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Thu, 19 Jun 2008 22:28:00 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2Q00F4KXUOC0A0@fe-sfbay-10.sun.com>; Thu, 19 Jun 2008 22:28:00 -0700 (PDT) Date: Thu, 19 Jun 2008 22:28:00 -0700 From: John Plocher Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <485B195B.3030400@sun.com> Sender: John.Plocher@sun.com To: Joseph Kowalski Cc: John Plocher , psarc-ext@sun.com Message-id: <485B3FE0.9020501@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <485B195B.3030400@sun.com> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 2013 Joseph Kowalski wrote: > Perhaps some view the unspecific reference of "one member" as making > this OK. I don't. In the whole email trail, this was one of the most succinct descriptions of the issue you were objecting to - as well as what seems to be some rationale for why the project faced such strong opposition from the ARC. > I would welcome any comments, private or public, from this audience > as how they react to private conversations I wasn't aware that this message was intended to be confidential. As far as I knew, it was ARC related email pertaining to this case, sent to the external-to-Sun project submitter - and thus to me. I didn't really look at the mail headers. This mail (and the thread it was from) played a /very large/ role in the project team's poor perception of Sun and the ARC process for this case, and (colorful as it was) did a good job of characterizing why you objected to this case. The only other messages that touched on this were: > If this "just a c-team issue", who gets to make this "product > decision"? I can buy that it might not be the ARC, but who? > Roland and an advocate? If Roland can just integrate "coreutils > should be 64-bits", can I almost immediately integrate "coreutils > should be 32-bits"? or > Its the switch. You nor I have access to that switch. I'm > just trying to figure out who has access to that switch. and > I finally see the need for an opinion. Its a formal way to tell > the c-team that they should to cast a *very* suspect eye at > the "coreutils + bash" integration request. Nothing wrong with > it, there just isn't anybody "at the switch". They should (IMHO) > place it on hold until somebody is "at the switch". Not nearly as cut and dried. I admit, I may have missed a better summary in the 100+ messages in the mail log. As I said, this is a draft opinion. I welcome replacement text for this section if you would care to provide it. -John (now really on vacation and out of email range...) From jek3@sun.com Thu Jun 19 23:19:58 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5K6JvLk017865 for ; Thu, 19 Jun 2008 23:19:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5K6JnjC006219; Fri, 20 Jun 2008 07:19:55 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00K05096IG00@brm-avmta-1.central.sun.com>; Fri, 20 Jun 2008 00:19:54 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R007BT0944HD0@brm-avmta-1.central.sun.com>; Fri, 20 Jun 2008 00:19:53 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5K6Jp3I832163; Thu, 19 Jun 2008 23:19:52 -0700 (PDT) Date: Thu, 19 Jun 2008 20:22:51 -1000 From: Joseph Kowalski Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <485B3FE0.9020501@Sun.Com> To: John Plocher Cc: John Plocher , psarc-ext@sun.com Message-id: <485B4CBB.9020901@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <485B195B.3030400@sun.com> <485B3FE0.9020501@Sun.Com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 2776 Just to be clear, you are defending the inclusion of private mail in a official opinion? John Plocher wrote: > Joseph Kowalski wrote: >> Perhaps some view the unspecific reference of "one member" as making >> this OK. I don't. > > In the whole email trail, this was one of the most succinct descriptions > of the issue you were objecting to - as well as what seems to be some > rationale for why the project faced such strong opposition from the ARC. Perhaps you considered: a) paraphrasing it b) contacting me about it > > I would welcome any comments, private or public, from this audience > > as how they react to private conversations > > I wasn't aware that this message was intended to be confidential. As > far as I knew, it was ARC related email pertaining to this case, sent > to the external-to-Sun project submitter - and thus to me. I didn't > really look at the mail headers. > > This mail (and the thread it was from) played a /very large/ role in > the project team's poor perception of Sun and the ARC process for this > case, and (colorful as it was) did a good job of characterizing why you > objected to this case. > > > The only other messages that touched on this were: > >> If this "just a c-team issue", who gets to make this "product >> decision"? I can buy that it might not be the ARC, but who? Roland >> and an advocate? If Roland can just integrate "coreutils >> should be 64-bits", can I almost immediately integrate "coreutils >> should be 32-bits"? > > or > >> Its the switch. You nor I have access to that switch. I'm just >> trying to figure out who has access to that switch. > > and > >> I finally see the need for an opinion. Its a formal way to tell >> the c-team that they should to cast a *very* suspect eye at >> the "coreutils + bash" integration request. Nothing wrong with >> it, there just isn't anybody "at the switch". They should (IMHO) >> place it on hold until somebody is "at the switch". > > Not nearly as cut and dried. I admit, I may have missed a better > summary in the 100+ messages in the mail log. The point is that the referenced message is not in the mail log. It only appeared in Roland's inbox. I have no clue how it escaped from there. Its particularly offensive to take such a quote out of context. If you read the whole message, you will note that there are a few other colorful bits in the message, many as inclusions. > As I said, this is a draft opinion. I welcome replacement text for > this section if you would care to provide it. Damage done, but it does need the "conclusion" derived from by observation. > > -John (now really on vacation and out of email range...) To be clear, I'm concerned more about ethics than the content (at this point). - jek3 From jek3@sun.com Thu Jun 19 23:39:04 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5K6d3Ti017944 for ; Thu, 19 Jun 2008 23:39:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5K6cxZM012828; Fri, 20 Jun 2008 07:39:01 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00C03150L400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Jun 2008 23:39:00 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R003ZW1507C30@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Jun 2008 23:39:00 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5K6cxNF833655; Thu, 19 Jun 2008 23:39:00 -0700 (PDT) Date: Thu, 19 Jun 2008 20:41:59 -1000 From: Joseph Kowalski Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <485B4CBB.9020901@sun.com> To: John Plocher Cc: John Plocher , psarc-ext@sun.com Message-id: <485B5137.9080304@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <485B195B.3030400@sun.com> <485B3FE0.9020501@Sun.Com> <485B4CBB.9020901@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 1266 Just another tibbit: > Perhaps you considered: > > a) paraphrasing it > > b) contacting me about it If you *had* contacted me about this, I would probably have said, "sure, just drop the last sentence of the first paragraph (ETOCOLORFULL) and drop the second paragraph (ETOLITTLECONTEXT or ENOTRELEVANT). It kinda does reflect my beliefs. However, I've already had a couple of queries about what the second paragraph was about. The reason it was there was because I believe we were all bombarded with a lot of complaining by Roland (Grown, Erk, etc.). I was only trying to thrown him a bone to acknowledge that there are a lot of issues which make things difficult for external community members. It really isn't relative to the discussion at hand. This should have been very clear, assuming you were presented with the full e-mail message. Also, John,... you knew that a smaller group was looking at "draft opinions" (Garrett, Glenn, Roland, John and myself). I looked at all of these iterations. Not one of them had anything close to this quotation. Can we say "blindsided"? Finally, don't you remember the advice from Gingell: `Never say "putback" just before you go on vacation`? Same applies to most e-mails. :-) - jek3 From Darren.Moffat@sun.com Fri Jun 20 05:54:02 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KCs1ET025131 for ; Fri, 20 Jun 2008 05:54:02 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5KCrqlc021407 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 20 Jun 2008 13:54:00 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00701IHZK700@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 05:53:59 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R002I0IHYW890@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 05:53:59 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5KCrwkr026503 for ; Fri, 20 Jun 2008 12:53:58 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2R00101FSQNO00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 13:53:58 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2R00DL5IHBF080@fe-emea-10.sun.com>; Fri, 20 Jun 2008 13:53:36 +0100 (BST) Date: Fri, 20 Jun 2008 13:53:35 +0100 From: Darren J Moffat Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: John Plocher Cc: psarc-ext@sun.com Message-id: <485BA84F.8070100@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 1705 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. 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. 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. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Fri Jun 20 06:40:31 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KDeUIe025715 for ; Fri, 20 Jun 2008 06:40:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5KDeOwn013460 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 20 Jun 2008 14:40:29 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00C05KNE7T00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 06:40:26 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R009YZKNDVH10@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 06:40:26 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5KDeO0D002637; Fri, 20 Jun 2008 09:40:24 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5KDeOCm002634; Fri, 20 Jun 2008 09:40:24 -0400 (EDT) Date: Fri, 20 Jun 2008 09:40:24 -0400 From: James Carlson Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> To: John Plocher Cc: psarc-ext@sun.com Message-id: <18523.45896.770076.461435@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> Status: RO Content-Length: 2083 John Plocher writes: > This is a *draft* opinion intended to be used as context for a vote. It > needs wordsmithing in several places, including the "not architectural" > sections in section 4. Contributions of "better words" would be very > much appreciated. It does need some wordsmithing, but that's not my main concern with it. Besides not really saying anything new (we've been immersed in the 32/64 bit issues for more than a decade now), and apparent improper handling of a private email conversation, I think section 4.3.2 is completely out of step with the goals of the Indiana community in building a reference distribution built on community involvement. The real issue there is that distributions need to set boundary conditions (including a set of platforms on which to run, which is explicitly *NOT* what this case is about, despite section 4.1.1), and not some architecturally irrelevant argument about who has 'standing' to make those distributor decisions. Because I think the out-of-context excerpt in 4.3.2 appears to suggest that Sun has the final say here, and not the distributor, and is thus quite destructive on the face of it, I would vote against this opinion as drafted. Without that section, I'd abstain. Without a project supporting an actual 64-bit-only platform under review, or some stronger policy about the requirement for 64-bit cleanliness (and not just "if you want, and you're not magical FOSS"), I don't think this says anything useful, so there's no reason to vote in favor. (Of course, if it provides some operational advantage, I have no problem with the original and now blown-out-of-proportion proposal to switch the SPARC GNU coreutils+bash to 64 bit. I also don't think it's an architectural matter at all, so we really didn't need to review this implementation choice. Why are we here again?) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From roland.mainz@nrubsig.org Fri Jun 20 07:38:40 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KEcbYs026463 for ; Fri, 20 Jun 2008 07:38:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5KEcPe5028679; Fri, 20 Jun 2008 22:38:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00C0FNC60U00@brm-avmta-1.central.sun.com>; Fri, 20 Jun 2008 08:38:30 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R00NRVNC60D80@brm-avmta-1.central.sun.com>; Fri, 20 Jun 2008 08:38:30 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5KEaLhs019205; Fri, 20 Jun 2008 14:38:29 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay43i.sun.com with ESMTP id BT-MMP-806778; Fri, 20 Jun 2008 14:38:29 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-41535916; Fri, 20 Jun 2008 14:38:27 +0000 (Z) Received: from mail-in-16.arcor-online.net ([151.189.21.56] [151.189.21.56]) by relay4i.sun.com with ESMTP id BT-MMP-34660054; Fri, 20 Jun 2008 14:38:26 +0000 (Z) Received: from mail-in-20-z2.arcor-online.net (mail-in-20-z2.arcor-online.net [151.189.8.85]) by mail-in-16.arcor-online.net (Postfix) with ESMTP id 3CDB21F721D; Fri, 20 Jun 2008 16:38:24 +0200 (CEST) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) by mail-in-20-z2.arcor-online.net (Postfix) with ESMTP id 27038109862; Fri, 20 Jun 2008 16:38:24 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-023-143.pools.arcor-ip.net [84.59.23.143]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id 62DA828ABA6; Fri, 20 Jun 2008 16:38:23 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m5KEcKx6004762; Fri, 20 Jun 2008 16:38:20 +0200 (CEST) Date: Fri, 20 Jun 2008 16:38:20 +0200 From: Roland Mainz Subject: Re: Spec update and draft opinion available for 2008/351 - SwitchSPARCGNU coreutils+bash from 32 to 64bit Sender: gisburn@jupiterb48.nrubsig.org To: James Carlson Cc: John Plocher , psarc-ext@sun.com Message-id: <485BC0DC.60F6C638@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.93/7407/Mon Jun 9 04:21:00 2008 on mail-in-07.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 2.117sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <18523.45896.770076.461435@gargle.gargle.HOWL> Status: RO Content-Length: 1864 James Carlson wrote: > John Plocher writes: [snip] > Because I think the out-of-context excerpt in 4.3.2 appears to suggest > that Sun has the final say here, and not the distributor, and is thus > quite destructive on the face of it, I would vote against this opinion > as drafted. > > Without that section, I'd abstain. Without a project supporting an > actual 64-bit-only platform under review, - There is one "well-known"[1] port of Solaris which runs on 64bit only hardware - the problem with "under review" is that the work is _not_ done by Sun. Right now they desperately try get the problem under control by adding "artificial" 32bit support on 64bit-only hardware to _avoid_ having to cleanup OS/Net+SFWNV themselves. If this attempt fails then this port is _DEAD_ (unless we find a way to make OS/Net+SFWNV 64bit clean). - One of the early attemps (e.g. shortly after OpenSolaris.org wass founded) of porting (Open-)Solaris Nevada to another platform simply died when the matching company figured out that 1) OS/Net is not 64bit clean 2) the usual reply was "you have to cleanup that yourself, we won't help" Guess why that company lost their interest ? At some point we need more ports to get the "diversity" from which Linux and the *BSD communities live from - it's not only "packages packages packages" what OpenSolaris needs - we need the ports, too. And there we've hit the bottom ("PPC" being "dormant", one dead-born because the company was scared away (see above) and the only currently active port is in trouble because of the 64bit issue) and won't make _any_ progress until the 64bit issue has been solved. [1]=The name is not public... yet. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL (;O/ \/ \O;) From carlsonj@phorcys.east.sun.com Fri Jun 20 07:57:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KEvJ8m026797 for ; Fri, 20 Jun 2008 07:57:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5KEvIxA018162 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 20 Jun 2008 15:57:19 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00103O7H7G00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 07:57:17 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R00K0OO7GPX50@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 07:57:17 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5KEnkkS003088; Fri, 20 Jun 2008 10:49:46 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5KEnkQO003085; Fri, 20 Jun 2008 10:49:46 -0400 (EDT) Date: Fri, 20 Jun 2008 10:49:46 -0400 From: James Carlson Subject: Re: Spec update and draft opinion available for 2008/351 - SwitchSPARCGNU coreutils+bash from 32 to 64bit In-reply-to: <485BC0DC.60F6C638@nrubsig.org> To: Roland Mainz Cc: John Plocher , psarc-ext@sun.com Message-id: <18523.50058.190861.265274@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <18523.45896.770076.461435@gargle.gargle.HOWL> <485BC0DC.60F6C638@nrubsig.org> Status: RO Content-Length: 1708 Roland Mainz writes: > James Carlson wrote: > > John Plocher writes: > [snip] > > Because I think the out-of-context excerpt in 4.3.2 appears to suggest > > that Sun has the final say here, and not the distributor, and is thus > > quite destructive on the face of it, I would vote against this opinion > > as drafted. > > > > Without that section, I'd abstain. Without a project supporting an > > actual 64-bit-only platform under review, > > - There is one "well-known"[1] port of Solaris which runs on 64bit only > hardware - the problem with "under review" is that the work is _not_ > done by Sun. Right now they desperately try get the problem under I'm glad that there is such a project. They, however, have not submitted anything to the ARC for the review, and thus, as I stated above, that project is *NOT UNDER REVIEW*. The ARC reviews projects that submit materials for review. We don't go out trolling for new things that we could review, nor do we normally try to guess at the requirements they might one day have. > control by adding "artificial" 32bit support on 64bit-only hardware to > _avoid_ having to cleanup OS/Net+SFWNV themselves. If this attempt fails > then this port is _DEAD_ (unless we find a way to make OS/Net+SFWNV > 64bit clean). That's their work to do. They can (and should) submit a case for review, particularly if they need to set a new "Big Rule" for all projects -- such as, say, requiring 64-bit cleanliness. That is *NOT* this case. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@sun.com Fri Jun 20 08:09:04 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KF94lt027022 for ; Fri, 20 Jun 2008 08:09:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5KF92F6059026 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 20 Jun 2008 09:09:04 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R0011JOR3Q300@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 20 Jun 2008 08:09:03 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R00KLSOQ1PS60@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 20 Jun 2008 08:08:27 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5KF8PGh015851 for ; Fri, 20 Jun 2008 15:08:25 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2R00401OGJ4Z00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 20 Jun 2008 16:08:25 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2R006T7OPYY700@fe-emea-10.sun.com>; Fri, 20 Jun 2008 16:08:23 +0100 (BST) Date: Fri, 20 Jun 2008 16:08:22 +0100 From: Darren J Moffat Subject: Re: Spec update and draft opinion available for 2008/351 - SwitchSPARCGNU coreutils+bash from 32 to 64bit In-reply-to: <485BC0DC.60F6C638@nrubsig.org> Sender: Darren.Moffat@sun.com To: Roland Mainz Cc: James Carlson , John Plocher , psarc-ext@sun.com Message-id: <485BC7E6.8000103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <18523.45896.770076.461435@gargle.gargle.HOWL> <485BC0DC.60F6C638@nrubsig.org> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 337 Roland Mainz wrote: > - There is one "well-known"[1] port of Solaris which runs on 64bit only > hardware - the problem with "under review" is that the work is _not_ > > [1]=The name is not public... yet. So well known that I don't know what it is and its name isn't public yet, come on get real it can't be both. -- Darren J Moffat From roland.mainz@nrubsig.org Fri Jun 20 08:18:28 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KFISSA027223 for ; Fri, 20 Jun 2008 08:18:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5KFI45S029468; Fri, 20 Jun 2008 16:18:26 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00E0TP6OVJ00@brm-avmta-1.central.sun.com>; Fri, 20 Jun 2008 09:18:24 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R00NFBP6M0DB0@brm-avmta-1.central.sun.com>; Fri, 20 Jun 2008 09:18:22 -0600 (MDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5KF6gZp029017; Fri, 20 Jun 2008 15:18:21 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay12i.sun.com with ESMTP id BT-MMP-223948; Fri, 20 Jun 2008 15:18:21 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-43350864; Fri, 20 Jun 2008 15:18:21 +0000 (Z) Received: from mail-in-06.arcor-online.net ([151.189.21.46] [151.189.21.46]) by relay1ib.sun.com with ESMTP id BT-MMP-1876848; Fri, 20 Jun 2008 15:18:21 +0000 (Z) Received: from mail-in-15-z2.arcor-online.net (mail-in-15-z2.arcor-online.net [151.189.8.32]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id D11EF31E7CE; Fri, 20 Jun 2008 17:18:19 +0200 (CEST) Received: from mail-in-02.arcor-online.net (mail-in-02.arcor-online.net [151.189.21.42]) by mail-in-15-z2.arcor-online.net (Postfix) with ESMTP id BE1E1725E00; Fri, 20 Jun 2008 17:18:19 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-084-059-023-143.pools.arcor-ip.net [84.59.23.143]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 50CC336E86D; Fri, 20 Jun 2008 17:18:19 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id m5KFIGMq004775; Fri, 20 Jun 2008 17:18:17 +0200 (CEST) Date: Fri, 20 Jun 2008 17:18:16 +0200 From: Roland Mainz Subject: Re: Spec update and draft opinion available for 2008/351 -SwitchSPARCGNU coreutils+bash from 32 to 64bit Sender: gisburn@jupiterb48.nrubsig.org To: Darren J Moffat Cc: James Carlson , John Plocher , psarc-ext@sun.com, roland.mainz@sun.com Message-id: <485BCA38.55A1BCA6@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: ClamAV 0.93/7407/Mon Jun 9 04:21:00 2008 on mail-in-02.arcor-online.net X-Virus-Status: Clean X-Antispam: No, score=0.0/5.0, scanned in 0.054sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <18523.45896.770076.461435@gargle.gargle.HOWL> <485BC0DC.60F6C638@nrubsig.org> <485BC7E6.8000103@Sun.COM> Status: RO Content-Length: 791 Darren J Moffat wrote: > Roland Mainz wrote: > > - There is one "well-known"[1] port of Solaris which runs on 64bit only > > hardware - the problem with "under review" is that the work is _not_ > > > > [1]=The name is not public... yet. > > So well known that I don't know what it is and its name isn't public > yet, come on get real it can't be both. I've been told to avoid using the name or the involved companies and use the term "well-known port" instead (welcome to "NDA"&co.). I can only get more specific using my @sun.com address to addresses within Sun (since I prefer to keep my job). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL (;O/ \/ \O;) From gdamore@sun.com Fri Jun 20 08:40:13 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KFeDIP027745 for ; Fri, 20 Jun 2008 08:40:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5KFeAEi005553 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 20 Jun 2008 09:40:12 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00G2NQ6ZBG00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 09:40:11 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R00MNUQ6XZVD0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 09:40:10 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5KFe9ZE019536 for ; Fri, 20 Jun 2008 08:40:09 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2R00M01Q2V6P00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 08:40:09 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2R002OFQ6XXND0@fe-sfbay-09.sun.com>; Fri, 20 Jun 2008 08:40:09 -0700 (PDT) Date: Fri, 20 Jun 2008 08:38:35 -0700 From: "Garrett D'Amore" Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: psarc-ext@sun.com Message-id: <485BCEFB.6040804@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 12254 John Plocher wrote: > Spec: > http://www.opensolaris.org/os/community/arc/caselog/2008/351/proposal > > Draft Opinion (also below): > http://www.opensolaris.org/os/community/arc/caselog/2008/351/opinion-draft-txt > > Notes: > I will be out of electronic communication on vacation for the next 2 weeks > > This is a *draft* opinion intended to be used as context for a vote. It > needs wordsmithing in several places, including the "not architectural" > sections in section 4. Contributions of "better words" would be very > much appreciated. > > I will catch up when (if?) I come back to civilization :-) > > -John > > ============= > Draft Opinion > ============= > > sun > microsystems Systems Architecture Committee > > _________________________________________________________________ > > Subject: Switch SPARC GNU coreutils+bash from 32 to > 64bit > > Submitted by: Roland Mainz > > File: PSARC/2008/351/opinion.ms > > Date: VOTE NEEDED > > Committee: Usual suspects: (John Plocher), Kais Bel- > gaied, Mark Carlson, James D. Carlson, Gar- > rett D'amore, Joseph Kowalski, Tim Marsland, > Richard Matthews, Darren Moffat, Glenn > Skinner, Bill Sommerfeld, Gary Winiger. > > Product Approval Committee: > > Solaris PAC > solaris-pac-opinion@sun.com > > 1. Summary > > There are emerging processor architectures where supporting > *any* 32-bit userland is problematic or impossible. > > There is a class of "limitations/bugs" in many utilities > related to the use of 32-bit data structures. > > This case sets 32/64 bit expectations going forward. > > When applying these guidelines, consider that "Everyone can, > most should and nobody must" use them. > I'd prefer to drop the the above sentence altogether. I really do think we want all of the "common" portable code to be 64-bit clean. > New code developed specifically for Solaris or OpenSolaris > certainly should be 64-bit clean. However, code imported > from another ecosystem shouldn't face that requirement; > there's no question that it's highly desirable, but such > code may bring other benefits that outweigh any deficiencies > that not being 64-bit clean might induce. > I'm not entirely convinced that we need to make this waiver explicit. Specifically, imported code is likely to already be 64-bit clean if it is used on 64-bit editions of Linux (amd64, alpha, probably other ports as well). Second, for "non-optional" programs that make up part of the core foundation (e.g. perl, sendmail, OpenSSL), the inability to use these programs on a 64-bit only port would represent a serious deficiency. (Conversely, the inability to use e.g. "unison" on a specific port might be unlikely to be noticed by many users of the port.) My preference here would be for language more along the lines of: "Generally, new and imported code should be 64-bit clean. However, there may be specific exceptions, especially for programs that are platform-specific. Any other cases where programs are not 64-bit clean should be considered a bug." > 2. Decision & Precedence Information > > The project is approved as specified in reference [1]. > > Projects following this policy may be delivered in minor > releases of any consolidation. > Why not patch releases? > This project sets precedent concerning 64-bit binaries. > > 3. Interfaces > > The project exports no interfaces. > > The project imports no interfaces. > > 4. Opinion > > The architecture here is simple - we need to be able to sup- > port 64 bit-only systems. This implies that it is a bug to > not be 64-bit clean. We also have 32-bit systems we need to > support, so it is also a bug to not be 32-bit clean. > > It may be reasonable to hold up code "we write" to a higher > standard than code that "we import from elsewhere", but, in > the end, this is a C-Team rather than ARC issue: The ARC > expects things to build correctly on both 32- and 64-bit > processor architectures, and it is up to the C-Teams and/or > Distro builders to choose how they will actually build > things. > I would change the above paragraph to read just: The ARC expects things to build correctly on both 32- and 64-bit processor architectures, and it is up to the C-Teams and/or Distro builders to choose how they will implement this. > Projects importing exteral software should consider trying > to compile 64-bit - and file bugs upstream if found. > > 4.1. Where do 64-bit binaries make sense? > > 4.1.1. On 64-bit-only processor architectures that do not > support 32-bit code, we must produce 64-bit code. > > When porting OpenSolaris to a totally new ISA, perhaps one > could skip the effort to build a 32-bit support, and *only* > do 64-bit, because at that point, there might not be any > need to support a legacy 32-bit environment. > > 4.1.2. On 64-bit processor architectures that support run- > ning 32-bit code, it is acceptable to have a mix of 32- and > 64- bit programs. > > The decision to provide 64-bit-only code, to use something > like isaexec() to provide both 32- and 64-bit code, or to > remain with 32-bit only code should be made on a case by > case basis. > > On x86/x64 systems, we have historically shipped an OS that > had the ability to boot and run the same OS image on both > 32- and 64-bit capable hardware. This opinion does nothing > to change that status quo. > > Converting everything to 64-bit isn't a mandate at this > time. 64-bit binaries provide certain advantages in avoid- > ing capacity limitations. These advantages come at a cost > that's becoming less burdensome over time as system capabil- > ities (speed, memory size, file system space) increase. The > trade-offs are shifting to make 64-bit binaries enough more > attractive that self-review may suffice for many cases that > propose to replace 32-bit binaries with corresponding 64-bit > binaries. But we are not at the point where we can support > blanket "do it all" or "no conversions need review" asser- > tions. > > 4.1.3. 32-bit-only processor architectures obviously can > not run 64-bit code. This implies that the build system > still needs to be able to produce 32-bit code, so things > need to remain "32-bit clean" as well. > > As with the 64-bit note above, the economic imperitives may > change such that 32-bit-only systems are no longer > "interesting" - at which point this guidance will need to be > updated. For now, deviations (either way) need justifica- > tion and associated review. > > 4.2. The "case by case" analysis mentioned above needs to > address the following issues: > > 4.2.1. Does the code have 32-bit limits? > > If so, are those limits addressable using mechanisms other > than 64-bit conversion? If so, consider using those > mechanisms to provide value on 32-bit platforms independent > from a decision to convert to 64-bit. (i.e., large file > awareness, instruction set, ...) > > 4.2.2. Is the code 64-bit clean? > > If not (due to source code design and implementation prob- > lems), bugs should filed against it. > > 4.2.3. Are there other utilities that should all be con- > verted together? > > Consider both within families (i.e., all the GNU utils) and > across (all the various flavors of grep...) > > 4.3. Non-architectural issues > > 4.3.1. Bitness parity between utilities in a "family" or > across the platforms supported by a release > > There was some discussion about whether we needed to convert > complete groupings of utilities as subprojects, either > because there was value in having like things be the same > bitness or because having them be different might be a call > generator (if gnugrep behaves differently on large files > than does /usr/bin/grep...). In the end, the Committee did > not see this "family grouping" as an ARC requirement. > > There was also discussion about bitness-related functional- > ity differences across platforms - a 32-bit binary on x86 > behaving differently than the same command on 64-bit SPARC, > for example. This difference was seen by the Committee as > being a natural differentiation between hardware platforms > with different capabilities, and not something that needed > ARC intervention. > Can we amend that somewhat, with something like this: However, on processors which are capable of running 64-bit programs (e.g. amd64), feature disparity between the program running on one 64-bit capable processor (amd64) and another (sparcv9) resulting from the decision to deliver 32-bit support for one of those processors might be considered a bug, particularly if the limitation is likely to be noticeable to users of the utility. The advice given in section 6.1 may be particularly apropos. > 4.3.2. Who gets to decide what changes get accepted into > "OpenSolaris", especially ones that affect the way the > "OpenSolaris Binaries" are built? > > One member asserted > "The real issue is that this isn't a change for you, or > even the community to decide. Where did you suddenly > become "product czar" for Sun's Solaris product? I > expect this self-review -> fast-track will simply > disappear. Its a product decision. I think it was > silly that you even suggested it. > > (Yea, I know the sources should be on the other side of > firewall and probably there should be a community con- > trolled distro, but that isn't the case.) > > 4.3.3. How to ensure that bitness regressions don't happen > > The project team was concerned that there might be source > code regressions without some mechanism to ensure that the > 64-bit clean work was used and tested. The Committee > referred the project team to the C-Team to work out > appropriate automation and testing policy and mechanisms to > guard against such things. > > 5. Minority Opinion(s) > > None > > 6. Advisory Information > > 6.1. Limitations of isaecec() > Spelling of isaexec. > Some members raised concerns that we may be missing out on > performance and features by not providing 64-bit versions of > programs by default, on those platforms which can run both > 32- and 64-bit programs (such as amd64). A good example of > this is grep, where a 64-bit grep can support processing of > larger files, and on amd64 may out perform the i386 version. > The current solution to supporting run-time selection of the > ISA for the binary, isaexec, has some known performance lim- > itations, and may not scale well, particularly for programs > that are executed frequently. Thus, the PAC is advised to > initiate a project to find an alternative to isaexec that > offers run time ISA selection, without less performance > impact than isaexec, and to make wider use of that alterna- > tive to provide 64-bit feature parity between both platforms > that are only 64-bit kernel capable (e.g. SPARC) and dual- > mode platforms running in 64-bit mode (e.g. amd64). > > 6.2. 64-bit time_t on 32-bit systems > > Some members also raised concerns about a class of bugs > related to the fact that 32-bit kernels, and 32-bit programs > as a result, are only able to keep time in 32-bit sized > integers. This can create problems, and bug disparities > between 32 and 64-bit versions of programs such as touch(1). > The PAC is advised to initiate a project to provide 64-bit > timekeeping and associated system calls (such as > lstat64_2(), utimes64(), or such) to 32-bit kernels and 32- > bit userland. > > 7. Appendices > > 7.1. Appendix A: Technical Changes Required > > None > > 7.2. Appendix B: Technical Changes Advised > > None > > 7.3. Appendix C: Reference Material > > Unless stated otherwise, path names are relative to the case > directory PSARC/2008/351. > > 3. Proposal File: proposal > > Mail log File: mail > > PSARC/2008/351 Copyright 2008 Sun Microsystems > > From gdamore@sun.com Fri Jun 20 09:35:34 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KGZXO3000592 for ; Fri, 20 Jun 2008 09:35:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5KGZUQ6012201 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 21 Jun 2008 00:35:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00405SR7U000@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 09:35:31 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R00KCESR7PHC0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 09:35:31 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5KGZVPH026810 for ; Fri, 20 Jun 2008 09:35:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2R00901SF8L800@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 09:35:31 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2R00200SR4C650@fe-sfbay-09.sun.com>; Fri, 20 Jun 2008 09:35:29 -0700 (PDT) Date: Fri, 20 Jun 2008 09:33:55 -0700 From: "Garrett D'Amore" Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <485BA84F.8070100@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: John Plocher , psarc-ext@sun.com Message-id: <485BDBF3.8040106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <485BA84F.8070100@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2273 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 From Darren.Moffat@sun.com Fri Jun 20 09:40:57 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KGeuVT000661 for ; Fri, 20 Jun 2008 09:40:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5KGerRb015042 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 21 Jun 2008 00:40:55 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00K0ZT06WB00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 10:40:54 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R00JYDT04IP50@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 10:40:53 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5KGeqZk026566 for ; Fri, 20 Jun 2008 16:40:52 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2R00501SXMF200@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 17:40:52 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2R00I3HSZSDA50@fe-emea-09.sun.com>; Fri, 20 Jun 2008 17:40:41 +0100 (BST) Date: Fri, 20 Jun 2008 17:40:40 +0100 From: Darren J Moffat Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <485BDBF3.8040106@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: John Plocher , psarc-ext@sun.com Message-id: <485BDD88.2040208@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <485BA84F.8070100@Sun.COM> <485BDBF3.8040106@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 499 Garrett D'Amore wrote: > Yes. Was large file support a POSIX issue, though? Yes. >> >> 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? Not of the top of my head but if necessary I could craft it though I think Don would be the best candidate to do this. -- Darren J Moffat From jek3@sun.com Fri Jun 20 11:40:32 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KIeV81003367 for ; Fri, 20 Jun 2008 11:40:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5KIeSEk017913; Fri, 20 Jun 2008 11:40:30 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R0060VYJHQB00@brm-avmta-1.central.sun.com>; Fri, 20 Jun 2008 12:40:29 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R00MW1YJHE460@brm-avmta-1.central.sun.com>; Fri, 20 Jun 2008 12:40:29 -0600 (MDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5KIeSwo930601; Fri, 20 Jun 2008 11:40:28 -0700 (PDT) Date: Fri, 20 Jun 2008 08:43:30 -1000 From: Joseph Kowalski Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <18523.45896.770076.461435@gargle.gargle.HOWL> To: James Carlson Cc: John Plocher , psarc-ext@sun.com Message-id: <485BFA52.70706@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <18523.45896.770076.461435@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 4654 James Carlson wrote: > Because I think the out-of-context excerpt in 4.3.2 appears to suggest > that Sun has the final say here, and not the distributor, and is thus > quite destructive on the face of it, I would vote against this opinion > as drafted. > I've pointed out that the out-of-context excerpt only serves to highlight the issue. There is no coherent conclusion from the members. This section is poorly formed along many different axis. More importantly, I was trying very hard (in the larger discussion) make the point that the distributor has the final say. The distributor is able to do anything, provided that they don't cross some line where they can still call it "based on OpenSolaris". Nexenta (sp?) married a gnu userland to a Solaris kernel - a rather significant product content decision. The missing context here is that Sun is a potential distributor - one of many. Sun is talking the OpenSolaris source and modifying it, if they should choose to do so. One of those choices is if they should deliver a 32-bit or 64-bit userland. Maybe it would be helpful if I outlined what I think this project *should* be doing: 1) Augment the build environment (Makefiles) such that a single flag/environment variable can toggle all the objects between 32-bit/64-bit. (Obviously, at the per utility level, objects that aren't 64-bit clean or should only be 32-bit for some other reason, would ignore this flag until "fixed".) 2) This project, and perhaps others, can go forth and make whatever objects they want obey this flag. Note, #1 and #2 are all about the source. There also isn't any architecture here. 3) Any distribution (where Sun is just one possible distribution) can set this flag as they see fit. Note, #3 is all about the binaries and product definition. No architecture here either. The project team (Roland) seems to believe that Sun is responsible to test (or provide test binaries) to check that his project doesn't regress in the future. It doesn't work that way. Sun (or any distribution) gets to test in the mode it desires. For over 10 years, I built a weekly build of Solaris (er, SunOS) and ran some tests which checked that some things I cared about didn't regress. (That "I" should be interpreted as "The Joseph Kowalski Project Team".) This and all project teams should follow this paradigm. If they don't do something similar, they may be "contributors", but they certainly aren't "maintainers". Digression follows: Perhaps some feel it is too difficult to build in this way. Scripts are posted (nightly, etc.) which make this easy. Lacking machine resources? Seems that OpenSolaris could easily find the resources to build a common build every night, even if it only used machine resources from individual contributors. (Its the community way). I *suspect* Sun could provide a couple of medium strength machines to help this. Consider: Source -> Binary -> Packages -> Distribution The first two arrows are trivial. The last arrow is very hard. You only need the first two to provide a test build which can completely controlled by the community - no distribution to be seen. (However, then the various communities can argue about how the flags get set. The distributions can just sit back and watch the discussions. In this particular case, I doubt that setting the flag for the test build to be "64-bit" would not be controversial.) It is my believe that the fact that OpenSolaris has *everything* leads many community members to believe they are building a product. They aren't. In the Linux world, its pretty obvious: kernel: from linux.org core userland: from gnu.org desktop: from gnome.org (or kde, or who ever) specialized components: too many to list, In OpenSolaris, its less obvious: kernel: from opensolaris.org core userland: from opensolaris.org desktop: from opensolaris.org specialized components: from opensolaris.org Note that desktop is only from opensolaris.org in name only. Its basically gnome, with a couple of maintainers working on the Solaris customizations. There was a big debate as to if there should be anything gnomish in OpenSolaris. It was decided to to so, only so that other OpenSolaris communities could get immediate access to Solaris specific gnome changes without being constrained by release dates (gnome.org has gone to a 6 month schedule). - jek3 From jek3@sun.com Fri Jun 20 11:42:10 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KIgAEj003467 for ; Fri, 20 Jun 2008 11:42:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5KIg8So018378; Fri, 20 Jun 2008 11:42:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00J09YM8UV00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 20 Jun 2008 11:42:08 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R004EKYM8EVA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 20 Jun 2008 11:42:08 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5KIg6Ew931534; Fri, 20 Jun 2008 11:42:07 -0700 (PDT) Date: Fri, 20 Jun 2008 08:45:09 -1000 From: Joseph Kowalski Subject: Re: Spec update and draft opinion available for 2008/351 - SwitchSPARCGNU coreutils+bash from 32 to 64bit In-reply-to: <485BC0DC.60F6C638@nrubsig.org> To: Roland Mainz Cc: James Carlson , John Plocher , psarc-ext@sun.com Message-id: <485BFAB5.9020200@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <18523.45896.770076.461435@gargle.gargle.HOWL> <485BC0DC.60F6C638@nrubsig.org> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 152 Roland Mainz wrote: > - There is one "well-known"[1] port of Solaris > ... > [1]=The name is not public... yet. > Made my day.... :-) - jek3 From jek3@sun.com Fri Jun 20 11:58:40 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KIwdIH004417 for ; Fri, 20 Jun 2008 11:58:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5KIwW1K004953; Sat, 21 Jun 2008 02:58:37 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00L09ZDNNO00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 20 Jun 2008 11:58:35 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R00440ZDNEQC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 20 Jun 2008 11:58:35 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5KIwYDq934395; Fri, 20 Jun 2008 11:58:34 -0700 (PDT) Date: Fri, 20 Jun 2008 09:01:36 -1000 From: Joseph Kowalski Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <485BFA52.70706@sun.com> To: James Carlson Cc: John Plocher , psarc-ext@sun.com Message-id: <485BFE90.8080602@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <18523.45896.770076.461435@gargle.gargle.HOWL> <485BFA52.70706@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 275 Joseph Kowalski wrote: > In this particular case, I doubt that setting the flag for the test > build to be "64-bit" would not be controversial.) Opps, double negative,... ... I doubt that setting the flag for the test build to be "64-bit" would be controversial. - jek3 From Alan.Coopersmith@sun.com Fri Jun 20 12:06:32 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KJ6VQB004614 for ; Fri, 20 Jun 2008 12:06:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5KJ6KE3014449 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 20 Jun 2008 20:06:31 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2R00801ZQUOE00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 13:06:30 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2R00MC0ZQTE270@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 13:06:30 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5KJ6Tv7026682 for ; Fri, 20 Jun 2008 12:06:29 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2R00401ZDCZ700@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 20 Jun 2008 12:06:29 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2R00F7LZQT4Z00@fe-sfbay-10.sun.com>; Fri, 20 Jun 2008 12:06:29 -0700 (PDT) Date: Fri, 20 Jun 2008 12:06:29 -0700 From: Alan Coopersmith Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <485BFA52.70706@sun.com> Sender: Alan.Coopersmith@sun.com To: Joseph Kowalski Cc: James Carlson , John Plocher , PSARC-ext@sun.com Message-id: <485BFFB5.6040503@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <18523.45896.770076.461435@gargle.gargle.HOWL> <485BFA52.70706@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1336 Joseph Kowalski wrote: > It is my believe that the fact that OpenSolaris has *everything* leads > many community members to believe they are building a product. They > aren't. Except now we are doing that too. Indiana is an opensolaris.org project, that the community is contributing to. Do you want to set the precedent that a project chartered by the OpenSolaris community to build a distro is not part of the world the OpenSolaris ARCs review? > In the Linux world, its pretty obvious: > > kernel: from linux.org > core userland: from gnu.org > desktop: from gnome.org (or kde, or who > ever) > specialized components: too many to list, distributions: fedoraproject.org, ubuntu.com, debian.org, etc. > In OpenSolaris, its less obvious: > > kernel: from opensolaris.org > core userland: from opensolaris.org > desktop: from opensolaris.org > specialized components: from opensolaris.org distributions: opensolaris.org/os/projects/indiana, genunix.org/.../belenix, berlios.de/.../schillix, nexenta.org, milax.org, etc. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From jek3@sun.com Fri Jun 20 12:29:33 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KJTXev005039 for ; Fri, 20 Jun 2008 12:29:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5KJTRMM023261; Fri, 20 Jun 2008 20:29:29 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2S00C090T40000@nwk-avmta-2.sfbay.sun.com>; Fri, 20 Jun 2008 12:29:28 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2S007UW0T4QC30@nwk-avmta-2.sfbay.sun.com>; Fri, 20 Jun 2008 12:29:28 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5KJTRZu939841; Fri, 20 Jun 2008 12:29:27 -0700 (PDT) Date: Fri, 20 Jun 2008 09:32:29 -1000 From: Joseph Kowalski Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <485BFFB5.6040503@sun.com> To: Alan Coopersmith Cc: James Carlson , John Plocher , PSARC-ext@sun.com Message-id: <485C05CD.5010404@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806200116.m5K1GdT8013652@sac.sfbay.sun.com> <18523.45896.770076.461435@gargle.gargle.HOWL> <485BFA52.70706@sun.com> <485BFFB5.6040503@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080225) Status: RO Content-Length: 2203 Alan Coopersmith wrote: > Joseph Kowalski wrote: > >> It is my believe that the fact that OpenSolaris has *everything* leads >> many community members to believe they are building a product. They >> aren't. >> > > Except now we are doing that too. Indiana is an opensolaris.org project, > that the community is contributing to. Do you want to set the precedent > that a project chartered by the OpenSolaris community to build a distro is > not part of the world the OpenSolaris ARCs review? > If you have any insight as to the differentiation between opensolaris.org and opensolaris.com? I believe the Indiana project of OpenSolaris is sometimes cast as a reference distribution or as a preview (but not clear as to what it is a preview of). In the first case (and probably the second - I can't tell) this just implies to me one organization is trying to wear two hats. That's fine. >> In the Linux world, its pretty obvious: >> >> kernel: from linux.org >> core userland: from gnu.org >> desktop: from gnome.org (or kde, or who >> ever) >> specialized components: too many to list, >> > > distributions: fedoraproject.org, ubuntu.com, debian.org, etc. > These are three very different beasts. It would be fun to pursue this, but not on this thread. It would be good to note that RedHat, SUSE and others are also such distributions, which make no pretense of being "communities". >> In OpenSolaris, its less obvious: >> >> kernel: from opensolaris.org >> core userland: from opensolaris.org >> desktop: from opensolaris.org >> specialized components: from opensolaris.org >> > > distributions: opensolaris.org/os/projects/indiana, genunix.org/.../belenix, > berlios.de/.../schillix, nexenta.org, milax.org, etc. > Very to the point. Why does the "community" get to make the product decisions for one specific distribution (indiana)? That said, I see my "digression" is leading this off-topic. My bad. Please focus on the stuff above the "digression". - jek3 From dwc@spartan.eng.sun.com Fri Jun 20 15:38:32 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KMcVcO010295 for ; Fri, 20 Jun 2008 15:38:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5KMcHwY021037; Sat, 21 Jun 2008 06:38:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2S00M019K4SD00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 20 Jun 2008 15:38:28 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2S006CP9K3HJ90@nwk-avmta-1.sfbay.Sun.COM>; Fri, 20 Jun 2008 15:38:28 -0700 (PDT) Received: from spartan.eng.sun.com (spartan.SFBay.Sun.COM [129.146.226.64]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5KMcQFT008419; Fri, 20 Jun 2008 15:38:26 -0700 (PDT) Received: from spartan.eng.sun.com (localhost [127.0.0.1]) by spartan.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id m5KMUvhr005982; Fri, 20 Jun 2008 15:30:57 -0700 (PDT) Received: (from dwc@localhost) by spartan.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id m5KMUvRn005981; Fri, 20 Jun 2008 15:30:57 -0700 (PDT) Date: Fri, 20 Jun 2008 15:30:57 -0700 (PDT) From: Don Cragun Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit To: Darren.Moffat@sun.com, gdamore@sun.com Cc: psarc-ext@sun.com Message-id: <200806202230.m5KMUvRn005981@spartan.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3090 >From psarc-intern-list-request@sun.com Fri Jun 20 09:42:26 2008 >Date: Fri, 20 Jun 2008 17:40:40 +0100 >From: Darren J Moffat >Subject: Re: Spec update and draft opinion available for 2008/351 - Switch > SPARC GNU coreutils+bash from 32 to 64bit >To: "Garrett D'Amore" >Cc: John Plocher , psarc-ext@sun.com >MIME-version: 1.0 >Content-transfer-encoding: 7BIT >User-Agent: Thunderbird 2.0.0.14 (X11/20080507) > >Garrett D'Amore wrote: >> Yes. Was large file support a POSIX issue, though? > >Yes. Not really. It was, and is, a C standard issue. The C standard's function prototypes for fseek() and ftell() specify that the file offset argument or return value is of type "long int" rather than the "off_t" type used by POSIX for lseek() and tell(). And, in an ILP32 environment, you can't use c89 to build an LFS application (because the 1989 ANSI C standard and the 1990 ISO C standard don't have the "long long" data type and don't allow it as an extension in standard conforming compilations. > >>> >>> 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? > >Not of the top of my head but if necessary I could craft it though I >think Don would be the best candidate to do this. This is not an API standards issue (except for applications that want to simultaneously conform an environment with a 64-bit time_t and to XPG3, POSIX.1-1988, or the 1989/1890 C standards. All of the affected interfaces specify time_t and implmentations are free to choose any integral type large enough to hold the desired range of timestamps. Backwards compatibility and ABIs are the issue here; not the current C, POSIX, and SUS standards. Note: Don't shoot the messenger for the following; I'm just reporting history... Tim Marsland decided that Solaris systems would not support 64-bit time_t's in 32-bit apps when we did our first 64-bit OS. IBM has already made access to 64-bit time_t's available to 32-bit applications. I think HP has also gone down this route, but I'm not sure. (HP supported Sun's position for a while, but I think they gave in later.) This issue comes up again every year or so, but Sun's consistent message so far has been that applications that want a 64-bit time_t should be built as LP64 (not ILP32) applications. (The combinations between various compilation modes and libraries [especially 3rd party libraries] makes providing a 64-bit time_t to 32-bit applications a much bigger project than it might seem at first glance. Note the disclaimers in the NOTES section of the lfcompile(5) man page; the restrictions would be worse for applications wanting a 64-bit time_t in an LFS environment. [I don't think it makes any sense at all to even consider providing a 64-bit time_t in an environment that doesn't also have a 64-bit off_t!]) - Don > > >-- >Darren J Moffat From gdamore@sun.com Fri Jun 20 16:02:02 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5KN22CT010937 for ; Fri, 20 Jun 2008 16:02:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5KN21nP025860; Fri, 20 Jun 2008 16:02:02 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2S00L05ANDL500@nwk-avmta-2.sfbay.sun.com>; Fri, 20 Jun 2008 16:02:01 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2S00KLLANDHL10@nwk-avmta-2.sfbay.sun.com>; Fri, 20 Jun 2008 16:02:01 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5KN21Bn015896; Fri, 20 Jun 2008 16:02:01 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2S00401AIM3F00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Fri, 20 Jun 2008 16:02:01 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K2S001E6ANCE620@fe-sfbay-09.sun.com>; Fri, 20 Jun 2008 16:02:00 -0700 (PDT) Date: Fri, 20 Jun 2008 16:00:25 -0700 From: "Garrett D'Amore" Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <200806202230.m5KMUvRn005981@spartan.eng.sun.com> Sender: Garrett.Damore@sun.com To: Don Cragun Cc: Darren.Moffat@sun.com, psarc-ext@sun.com Message-id: <485C3689.7020703@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200806202230.m5KMUvRn005981@spartan.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 3579 Thanks for the clarification. And I agree, 64-bit time_t's should automatically presume that large file offsets are *also* in use. I don't think 64-bit time_t's make any of the caveats for large file offsets worse. I.e. I think the same NOTES would apply to both cases. -- Garrett Don Cragun wrote: > >From psarc-intern-list-request@sun.com Fri Jun 20 09:42:26 2008 > >> Date: Fri, 20 Jun 2008 17:40:40 +0100 >> From: Darren J Moffat >> Subject: Re: Spec update and draft opinion available for 2008/351 - Switch >> SPARC GNU coreutils+bash from 32 to 64bit >> To: "Garrett D'Amore" >> Cc: John Plocher , psarc-ext@sun.com >> MIME-version: 1.0 >> Content-transfer-encoding: 7BIT >> User-Agent: Thunderbird 2.0.0.14 (X11/20080507) >> >> Garrett D'Amore wrote: >> >>> Yes. Was large file support a POSIX issue, though? >>> >> Yes. >> > > Not really. It was, and is, a C standard issue. > > The C standard's function prototypes for fseek() and ftell() specify > that the file offset argument or return value is of type "long int" > rather than the "off_t" type used by POSIX for lseek() and tell(). > > And, in an ILP32 environment, you can't use c89 to build an LFS > application (because the 1989 ANSI C standard and the 1990 ISO C > standard don't have the "long long" data type and don't allow it as > an extension in standard conforming compilations. > > >>>> 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? >>> >> Not of the top of my head but if necessary I could craft it though I >> think Don would be the best candidate to do this. >> > > This is not an API standards issue (except for applications that want > to simultaneously conform an environment with a 64-bit time_t and to > XPG3, POSIX.1-1988, or the 1989/1890 C standards. All of the affected > interfaces specify time_t and implmentations are free to choose any > integral type large enough to hold the desired range of timestamps. > Backwards compatibility and ABIs are the issue here; not the current C, > POSIX, and SUS standards. > > Note: Don't shoot the messenger for the following; I'm just reporting > history... > Tim Marsland decided that Solaris systems would not support 64-bit > time_t's in 32-bit apps when we did our first 64-bit OS. IBM has > already made access to 64-bit time_t's available to 32-bit > applications. I think HP has also gone down this route, but I'm not > sure. (HP supported Sun's position for a while, but I think they gave > in later.) This issue comes up again every year or so, but Sun's > consistent message so far has been that applications that want a 64-bit > time_t should be built as LP64 (not ILP32) applications. (The > combinations between various compilation modes and libraries > [especially 3rd party libraries] makes providing a 64-bit time_t to > 32-bit applications a much bigger project than it might seem at first > glance. Note the disclaimers in the NOTES section of the lfcompile(5) > man page; the restrictions would be worse for applications wanting a > 64-bit time_t in an LFS environment. [I don't think it makes any sense > at all to even consider providing a 64-bit time_t in an environment > that doesn't also have a 64-bit off_t!]) > > - Don > > >> -- >> Darren J Moffat >> From Joerg.Schilling@fokus.fraunhofer.de Tue Jun 24 04:12:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5OBCeu4005439 for ; Tue, 24 Jun 2008 04:12:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5OBCa9I011666; Tue, 24 Jun 2008 12:12:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2Y00I03SH13500@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Jun 2008 04:12:37 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2Y00DQLSH1P070@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Jun 2008 04:12:37 -0700 (PDT) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5OAqVFE025444; Tue, 24 Jun 2008 11:12:36 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay24i.sun.com with ESMTP id BT-MMP-658838; Tue, 24 Jun 2008 11:12:36 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-48162901; Tue, 24 Jun 2008 11:12:29 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay21i.sun.com with ESMTP id BT-MMP-12171059; Tue, 24 Jun 2008 11:12:29 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw22] (8.14.2+/8.14.2) with ESMTP id m5OB8SZG014107; Tue, 24 Jun 2008 13:08:28 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5OB8RGg014102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jun 2008 13:08:28 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5OB8Rh8020006; Tue, 24 Jun 2008 13:08:27 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 13:08:27 +0200 Date: Tue, 24 Jun 2008 13:08:27 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Spec update and draft opinion available for 2008/351 - Switch SPARC GNU coreutils+bash from 32 to 64bit In-reply-to: <485C3689.7020703@sun.com> To: gdamore@sun.com, don.cragun@sun.com Cc: psarc-ext@sun.com Message-id: <4860d5ab.QWzjTTxxWyiFqlKy%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 1.162sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200806202230.m5KMUvRn005981@spartan.eng.sun.com> <485C3689.7020703@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 24 Jun 2008 11:08:27.0693 (UTC) FILETIME=[A0CD45D0:01C8D5EA] Status: RO Content-Length: 1051 "Garrett D'Amore" wrote: > Thanks for the clarification. > > And I agree, 64-bit time_t's should automatically presume that large > file offsets are *also* in use. > > I don't think 64-bit time_t's make any of the caveats for large file > offsets worse. I.e. I think the same NOTES would apply to both cases. The "Large File Summit" in 1995 was needed because the POSIX and the C standard at that time did not allow to have "fundamental system types" be greater than a long. The "Large File Summit" unfortunately did not include time_t. Since December 2001 with POSIX.1-2001, it is no longer forbidden to have e.g. time_t that is bigger than a long. For now, even the default compile mode in theory could use a 64 bit time_t. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From iszczesniak@gmail.com Wed Jun 25 12:33:09 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PJX8bt012064 for ; Wed, 25 Jun 2008 12:33:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5PJX5Hv027544 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jun 2008 20:33:08 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3100901AB7HC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 12:33:07 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K31008XPAASYK40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jun 2008 12:33:06 -0700 (PDT) Received: from relay18i.sun.com (ip128.net129179-4.block1.us.syntegra.com [129.179.4.128]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5PJWpqq027874 for ; Wed, 25 Jun 2008 19:32:51 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay18i.sun.com with ESMTP id BT-MMP-1194106 for PSARC-ext@sun.com; Wed, 25 Jun 2008 19:32:51 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-437021 for PSARC-ext@sun.com; Wed, 25 Jun 2008 19:32:51 +0000 (Z) Received: from wf-out-1314.google.com ([209.85.200.175] [209.85.200.175]) by relay1ib.sun.com with ESMTP id BT-MMP-15110308 for PSARC-ext@sun.com; Wed, 25 Jun 2008 19:32:51 +0000 (Z) Received: by wf-out-1314.google.com with SMTP id 27so3087294wfd.17 for ; Wed, 25 Jun 2008 12:32:48 -0700 (PDT) Received: by 10.143.19.16 with SMTP id w16mr7115731wfi.223.1214422367992; Wed, 25 Jun 2008 12:32:47 -0700 (PDT) Received: by 10.143.191.3 with HTTP; Wed, 25 Jun 2008 12:32:47 -0700 (PDT) Date: Wed, 25 Jun 2008 21:32:47 +0200 From: "I. Szczesniak" Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: <18500.18219.433958.307965@gargle.gargle.HOWL> To: James Carlson Cc: Alan Coopersmith , PSARC-ext@sun.com, "Richard L. Hamilton" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lmUVJsLbo3CNPmkgutjI519QYFFOrN/YkL8HxLDHL5Q=; b=gu/cLhdOSfxtksGYV0B9wZKvZPqZbxVp9ApAtYIEmQw7lINcLW0G/oucuNq9MT4oy6 3BHAt1PcT1YnB0tLJ4DFCgG3gykjNxJFhPxA8GhnY3gdYlH10E7Nuy+FIBMi4iBHe3T4 mfDezAxSNjZ/KxSuwHc8SeVdgT4WseLVJRJnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LMpf6Qr9if08lTZtiCGz4p3XovNdBJNnMMvLdwr3ftfK6+pvjDHgPWxsuXfP5Unt09 AIt9T4yA+8cld8g/llcPJAS3BPO8UGBlgBZpSeORmbfZ/uX1ZM0OxKPoifczfLfydnRY A+jxbUG/0Xb/L8CKOFUUwMUpS+R6ADPteX7Dc= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.055sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> <18500.16414.347283.124172@gargle.gargle.HOWL> <18500.18219.433958.307965@gargle.gargle.HOWL> Status: RO Content-Length: 1019 On 6/2/08, James Carlson wrote: > I. Szczesniak writes: > > On 6/2/08, James Carlson wrote: > > > > It's also lifted if you call enable_extended_FILE_stdio(3C), use the > > > extendedFILE.so.1 preload, or 'F' is used as the last character in the > > > fopen(3C) mode string. > > > > FYI, enable_extended_FILE_stdio(3C) is incompatible to many > > applications, including coreutil. Using a FD > 256 crashes such > > applications. > > > "Coreutil"? As in GNU coreutils? Yes. > If there's a problem here, and it's not just broken code in the > application, then filing bugs would help. I searched for, but did not > find, any references to this problem either at any external site or in > the bug databases. We've send a bug report to the coreutils maintainers in July 2007 and received the response that "this is a bug in Solaris stdio and that the extended FILE facility is a hack which the GNU coreutils maintainers are not going to support". Irek From carlsonj@phorcys.east.sun.com Wed Jun 25 13:04:12 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5PK4CKP012887 for ; Wed, 25 Jun 2008 13:04:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5PK46aH009912; Wed, 25 Jun 2008 21:04:09 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3100A05BQVSQ00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 13:04:07 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3100AHABQVKP00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jun 2008 13:04:07 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5PJfbj3009351; Wed, 25 Jun 2008 15:41:37 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5PJfbsc009348; Wed, 25 Jun 2008 15:41:37 -0400 (EDT) Date: Wed, 25 Jun 2008 15:41:37 -0400 From: James Carlson Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: To: "I. Szczesniak" Cc: Alan Coopersmith , PSARC-ext@sun.com, "Richard L. Hamilton" Message-id: <18530.40817.561233.823423@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> <18500.16414.347283.124172@gargle.gargle.HOWL> <18500.18219.433958.307965@gargle.gargle.HOWL> Status: RO Content-Length: 1772 I. Szczesniak writes: > On 6/2/08, James Carlson wrote: > > If there's a problem here, and it's not just broken code in the > > application, then filing bugs would help. I searched for, but did not > > find, any references to this problem either at any external site or in > > the bug databases. > > We've send a bug report to the coreutils maintainers in July 2007 and > received the response that "this is a bug in Solaris stdio and that > the extended FILE facility is a hack which the GNU coreutils > maintainers are not going to support". Sigh. That really doesn't explain what the claimed "bug" might be. Filing a CR with details would be nice. As for the extended FILE bits, I think that if they don't want to port to Solaris, then that's entirely their right. The clear alternative would be for someone in OpenSolaris-land to fork the GNU coreutil source in order to provide the desired port. That's how the world deals with intransigent maintainers. I doubt those maintainers are interested, but that "hack" was the only real choice we had when faced with binary compatibility problems. Old applications were compiled with a version of fileno() as a macro, and that macro accessed a single byte in the FILE structure. We've long since fixed that problem, but we're always constrained by binary compatibility, and simply telling everyone "recompile now" was unacceptable. I don't think they need to like the answer, but I also don't think that means it's wrong ... or that they're right about this. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Joerg.Schilling@fokus.fraunhofer.de Thu Jun 26 03:02:45 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5QA2ixZ012184 for ; Thu, 26 Jun 2008 03:02:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5QA2aM6017157; Thu, 26 Jun 2008 18:02:39 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3200F03EKFDT00@brm-avmta-1.central.sun.com>; Thu, 26 Jun 2008 04:02:39 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K32009V1EKEJV30@brm-avmta-1.central.sun.com>; Thu, 26 Jun 2008 04:02:39 -0600 (MDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5QA1MPA013353; Thu, 26 Jun 2008 10:02:38 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay12i.sun.com with ESMTP id BT-MMP-442545; Thu, 26 Jun 2008 10:02:38 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-61072406; Thu, 26 Jun 2008 10:02:37 +0000 (Z) Received: from mailgw1.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay1ib.sun.com with ESMTP id BT-MMP-4589761; Thu, 26 Jun 2008 10:02:37 +0000 (Z) Received: from mailgw1.fraunhofer.de (localhost [127.0.0.1]) by mailgw1.fraunhofer.de[host mailgw23] (8.14.2+/8.14.2) with ESMTP id m5QA2U25021752; Thu, 26 Jun 2008 12:02:30 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw1.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m5QA2UfJ021745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jun 2008 12:02:30 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m5QA2Tq3023786; Thu, 26 Jun 2008 12:02:30 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 12:02:30 +0200 Date: Thu, 26 Jun 2008 12:02:29 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: [Fwd: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351] In-reply-to: <18530.40817.561233.823423@gargle.gargle.HOWL> To: james.d.carlson@sun.com, iszczesniak@gmail.com Cc: rlhamil@smart.net, PSARC-ext@sun.com, Alan.Coopersmith@sun.com Message-id: <48636935.MuTnybp+89M1Gx6j%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=0.0/5.0, scanned in 0.310sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4844391E.1070504@Sun.Com> <48443AC2.7030501@sun.com> <18500.16414.347283.124172@gargle.gargle.HOWL> <18500.18219.433958.307965@gargle.gargle.HOWL> <18530.40817.561233.823423@gargle.gargle.HOWL> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 26 Jun 2008 10:02:30.0030 (UTC) FILETIME=[BEAD52E0:01C8D773] Status: RO Content-Length: 840 James Carlson wrote: > As for the extended FILE bits, I think that if they don't want to port > to Solaris, then that's entirely their right. The clear alternative > would be for someone in OpenSolaris-land to fork the GNU coreutil > source in order to provide the desired port. That's how the world > deals with intransigent maintainers. Do not expect that the GNU tools will be "ported to Solaris", they are not even ported to linux.... GNU tar does not implement a single Linux specific feature, star does. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily