Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]
James C. McPherson writes: Are there any other issues or questions that we need to address with this RFE - at least from PSARC's point of view? Certainly none from me. -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]
James C. McPherson writes: Are there any other issues or questions that we need to address with this RFE - at least from PSARC's point of view? Certainly none from me. Nor from me. Gary.. P.S. silence is generally as sign of approval
Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]
James Carlson wrote: 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. Following up on your and Bill's question, we're requesting a Minor binding for the rfe. Are there any other issues or questions that we need to address with this RFE - at least from PSARC's point of view? thankyou in advance, James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems
Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]
Jason King wrote: Missed you on the CC.. -- Forwarded message -- From: Jason King jason at ansipunx.net Date: Sep 5, 2007 5:29 PM Subject: Re: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review] To: Bill Sommerfeld sommerfeld at sun.com Cc: Alan Hargreaves ah89892 at sac.sfbay.sun.com On 9/5/07, Bill Sommerfeld sommerfeld at sun.com 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
Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]
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 james.d.carlson at sun.com 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
Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]
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
Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]
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 james.d.carlson at sun.com 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
