From ah89892@sac.sfbay.sun.com Tue Sep 4 23:31:45 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l856VjxU007636 for ; Tue, 4 Sep 2007 23:31:45 -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 l856T02h006477; Tue, 4 Sep 2007 23:29:00 -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 <0JNV0090FU0CKD00@brm-avmta-1.central.sun.com>; Wed, 05 Sep 2007 00:29:00 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNV009GLU0B4ZD0@brm-avmta-1.central.sun.com>; Wed, 05 Sep 2007 00:28:59 -0600 (MDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l856Sw3k007977; Tue, 04 Sep 2007 23:28:59 -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 l856Vg4U007631; Tue, 04 Sep 2007 23:31:42 -0700 (PDT) Received: (from ah89892@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l856Vg5F007627; Tue, 04 Sep 2007 23:31:42 -0700 (PDT) Date: Tue, 04 Sep 2007 23:31:42 -0700 (PDT) From: Alan Hargreaves Subject: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review] To: PSARC-ext@sun.com Cc: jason@ansipunx.net Message-id: <200709050631.l856Vg5F007627@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2540 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Unencumbered libdisasm for Sparc 1.2. Name of Document Author/Supplier: Author: James McPherson 1.3 Date of This Document: 04 September, 2007 4. Technical Description I'm sponsoring this fast track for James McPherson and Jason King (jason.brian.king@gmail.com). As it does not modify any interfaces and is a drop in replacement for the existing closed library, I think it qualifies for self-review, but if anyone disagrees, let me know and I'll promote it to a fast track. The case is being logged for the record. 1. Introduction 1.1. Project/Component Working Name: Unencumbered libdisasm for Sparc 1.2. Name of Document Author/Supplier: Author: James McPherson 1.3 Date of This Document: 03 September 2007 4. Technical Description Background: ----------- Building Solaris and OpenSolaris for the Sparc architecture requires the use of a closed library, libdisasm. Problem: -------- The libdisasm library for Sparc is part of the closed binaries which ON delivers to OpenSolaris. It appears there isn't an easy way to open the existing code, therefore a non-encumbered reimplementation is needed. This is critical for OpenSolaris success since it is one of the few libraries that is required for the build process. libdisasm.so's closed status makes the OpenSolaris community dependent on Sun to deliver timely copies of the closed source binary in order to build ON (unlike most of the closed binaries) for the Sparc architecture. Solution: --------- This project delivers an unencumbered libdisasm for sparc, written by an OpenSolaris community member (Jason King, jason.brian.king@gmail.com) and licensed under CDDL. Interfaces: ----------- This is a drop-in replacement for libdisasm. For further details, please see PSARC 2005/673 dis(1) options and libdisasm.so.1 References: ----------- LSARC 1997/248 libdisasm PSARC 2005/673 dis(1) options and libdisasm.so.1 6596739 need non-encumbered libdisasm.so.1 for sparc 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From James.McPherson@Sun.COM Thu Sep 6 15:44:33 2007 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 l86MiWm4009891 for ; Thu, 6 Sep 2007 15:44:32 -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 l86Mfjdk007729 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 7 Sep 2007 06:41:46 +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 <0JNY00A05XPL9L00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Sep 2007 15:41:45 -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 <0JNY000PKXPJ36B0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Sep 2007 15:41:45 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l86MfhZ4011776 for ; Thu, 06 Sep 2007 22:41:43 +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 <0JNY00J01XIPSW00@mail-apac.sun.com> (original mail from James.McPherson@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 Sep 2007 06:41:43 +0800 (SGT) Received: from [10.7.251.162] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JNY00BH6XPFX71C@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 Sep 2007 06:41:43 +0800 (SGT) Date: Fri, 07 Sep 2007 08:41:38 +1000 From: "James C. McPherson" Subject: Re: Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review] In-reply-to: Sender: James.McPherson@Sun.COM To: psarc-ext@Sun.COM Cc: Jason King Reply-to: James.McPherson@Sun.COM Message-id: <46E08222.7070105@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709050631.l856Vg5F007627@sac.sfbay.sun.com> <1189005733.3532.32.camel@localhost> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 3104 Jason King wrote: > Missed you on the CC.. > > ---------- Forwarded message ---------- > From: Jason King > Date: Sep 5, 2007 5:29 PM > Subject: Re: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review] > To: Bill Sommerfeld > Cc: Alan Hargreaves > > > On 9/5/07, Bill Sommerfeld wrote: >> I don't see a statement of interface stability or a release binding >> (Minor? Patch?) >> >> The only thing that makes this arc-visible is the fact that there are in >> fact some minor changes to the instruction decoding; replacing one >> implementation with another that behaves exactly the same is a >> non-event. So something changed but the case is silent on this... >> >> I would have expected a brief summary of the discussion on >> opensolaris-code as part of the case materials. > > I don't have the necessary background on Sun's policy for release > bindings to state what the appropriate answer would be, nor to comment > in the interface stability. I would suspect for the interface > stability at least, it would match whatever the current classification > for the current library is. We're requesting a release binding of micro. There's no intention of pushing this back into Solaris 10. > As for changes, there are a few cases where the current closed source > bin outputs incorrect output (unfortunately, the sparc system I have > been using for testing is unavailable at the moment, so I cannot give > specific binaries for examples right now, though I can comment on the > errors themselves). I have not carried those forward. > > There are some cases where it is inconsistent about it's use of > synthetic instructions -- this one gets very hard to nail down without > access to the current source. For example, 'not' is only emitted in > certain cases, even when it would be correct in others. I just opted > to emit 'not' whenever the conditions were correct, instead of trying > to figure out which permutations happened to get 100% same behavior. > > Would documenting which synthetic instructions are emitted, as well as > which instructions the current library outputs incorrectly satisfy any > ARC requirements? > > As for interfaces, I also don't have any way to know if there are any > existing undocumented interfaces that otherwise might change. The one > thing I guess might be considered a new interface is in the .so > version (as opposed when it's built for kmdb), it supports the setting > of an environment variable _LIBDISASM_DEBUG that can cause information > about the instruction decoding to be sent to stderr as well as control > the use of synthetic instructions. I'm not sure what would an > appropriate classification if this is something that needs to be > documented. > > Just let me know what needs to be done. Re the ARC-visibility, my understanding was that we needed a fasttrack due to moving from closed to open. I'm quite happy to be mistaken on that front! James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems From carlsonj@phorcys.east.sun.com Fri Sep 7 04:10:25 2007 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 l87BAOQi021586 for ; Fri, 7 Sep 2007 04:10:24 -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 l87B7YT1023432; Fri, 7 Sep 2007 19:07:36 +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 <0JNZ00801W8NGM00@brm-avmta-1.central.sun.com>; Fri, 07 Sep 2007 05:07:36 -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 <0JNZ00LUQW8NQE70@brm-avmta-1.central.sun.com>; Fri, 07 Sep 2007 05:07:35 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l87AqZJO134646; Fri, 07 Sep 2007 06:52:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l87AqZcQ134643; Fri, 07 Sep 2007 06:52:35 -0400 (EDT) Date: Fri, 07 Sep 2007 06:52:35 -0400 From: James Carlson Subject: Re: Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review] In-reply-to: <46E08222.7070105@Sun.COM> To: James.McPherson@sun.com Cc: psarc-ext@sun.com, Jason King Message-id: <18145.11635.539868.996171@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.2.0.264296 References: <200709050631.l856Vg5F007627@sac.sfbay.sun.com> <1189005733.3532.32.camel@localhost> <46E08222.7070105@Sun.COM> Status: RO Content-Length: 2197 James C. McPherson writes: > We're requesting a release binding of micro. There's no intention > of pushing this back into Solaris 10. Oh. There aren't any Micro releases on the horizon, so that's a little confusing. Using that binding means "Nevada only" for now, the same as a Minor release binding. > > There are some cases where it is inconsistent about it's use of > > synthetic instructions -- this one gets very hard to nail down without > > access to the current source. For example, 'not' is only emitted in > > certain cases, even when it would be correct in others. I just opted > > to emit 'not' whenever the conditions were correct, instead of trying > > to figure out which permutations happened to get 100% same behavior. I would consider the specific instruction decoded in any given case (where there are reasonable and "legal" [per SPARC documentation] variants) to be "Not an Interface" in ARC terminology. It's visible and interesting behavior to users, but not something that's documented or that anyone could expect to rely on. > > version (as opposed when it's built for kmdb), it supports the setting > > of an environment variable _LIBDISASM_DEBUG that can cause information > > about the instruction decoding to be sent to stderr as well as control > > the use of synthetic instructions. I'm not sure what would an > > appropriate classification if this is something that needs to be > > documented. That's also undocumented, and looks like a Project Private detail. > Re the ARC-visibility, my understanding was that we > needed a fasttrack due to moving from closed to open. > I'm quite happy to be mistaken on that front! Not so. Neither location of the source in the tree nor the license applied are generally architectural issues. With a Micro or Minor binding, I think this one is simplest of cases. (Even with a Patch binding, I think it's fairly reasonable. I can understand, though, why it's not interesting as a patch.) -- James Carlson, Solaris Networking Sun Microsystems / 1 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 Sep 7 04:17:59 2007 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 l87BHxJZ021646 for ; Fri, 7 Sep 2007 04:17: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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l87BFAJ9008041 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 7 Sep 2007 12:15:11 +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 <0JNZ0080JWL9XF00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 Sep 2007 05:15:10 -0600 (MDT) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JNZ00LIZWL7QH80@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 Sep 2007 05:15:08 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l87BF735007092 for ; Fri, 07 Sep 2007 11:15:07 +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 <0JNZ00A01W4ENY00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 Sep 2007 12:15:07 +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 <0JNZ00CIOWL3XT10@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 Sep 2007 12:15:04 +0100 (BST) Date: Fri, 07 Sep 2007 12:15:03 +0100 From: Darren J Moffat Subject: Re: Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review] In-reply-to: <18145.11635.539868.996171@gargle.gargle.HOWL> Sender: Darren.Moffat@sun.com To: James Carlson Cc: James.McPherson@sun.com, psarc-ext@sun.com, Jason King Message-id: <46E132B7.9010907@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200709050631.l856Vg5F007627@sac.sfbay.sun.com> <1189005733.3532.32.camel@localhost> <46E08222.7070105@Sun.COM> <18145.11635.539868.996171@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070731) Status: RO Content-Length: 871 James Carlson wrote: > James C. McPherson writes: >> We're requesting a release binding of micro. There's no intention >> of pushing this back into Solaris 10. > > Oh. There aren't any Micro releases on the horizon, so that's a > little confusing. > > Using that binding means "Nevada only" for now, the same as a Minor > release binding. I don't see why it is confusing. To me that says that is is low risk but not deemed low enough to do in a patch (patch and micro really aren't the same because the delivery mechanism is different and patches (usually) need to be able to be reversed yet micro releases don't need to be downgraded. The current release in progress being "higher" than micro isn't really an issue here. If on the other hand the current release was micro and a case requested minor there would be something to discuss. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Fri Sep 7 04:43:15 2007 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 l87BhFNr021877 for ; Fri, 7 Sep 2007 04:43:15 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l87BeBcp017539; Fri, 7 Sep 2007 12:40:25 +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 <0JNZ00D01XRBWS00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 07 Sep 2007 04:40:23 -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 <0JNZ00778XRBIAC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 07 Sep 2007 04:40:23 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l87BPO8F134746; Fri, 07 Sep 2007 07:25:24 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l87BPNCV134743; Fri, 07 Sep 2007 07:25:23 -0400 (EDT) Date: Fri, 07 Sep 2007 07:25:23 -0400 From: James Carlson Subject: Re: Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review] In-reply-to: <46E132B7.9010907@Sun.COM> To: Darren J Moffat Cc: psarc-ext@sun.com, James.McPherson@sun.com, Jason King Message-id: <18145.13603.940362.396236@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.2.0.264296 References: <200709050631.l856Vg5F007627@sac.sfbay.sun.com> <1189005733.3532.32.camel@localhost> <46E08222.7070105@Sun.COM> <18145.11635.539868.996171@gargle.gargle.HOWL> <46E132B7.9010907@Sun.COM> Status: RO Content-Length: 822 Darren J Moffat writes: > James Carlson wrote: > > Using that binding means "Nevada only" for now, the same as a Minor > > release binding. > > I don't see why it is confusing. To me that says that is is low risk It's confusing because many project teams use "Micro" by mistake when they actually mean "Patch." We then run into last-minute updates when the C-team calls them on it. It's almost always an error. I have no problem with "Micro" when used correctly -- though it's slightly odd when there are no Micro vehicles around and none contemplated -- but the chance of error seems high. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677