Nicolas Williams wrote:
> On Mon, Nov 30, 2009 at 01:51:36PM -0800, Scott Rotondo wrote:
>> I agree that it would be better to integrate these FOSS "familiarity"
>> packages in /contrib, at least initially. It would be a more accurate
>> portrayal of what people are actually getting from us.
>>
>
George Vasick writes:
> OK, got it. You will still see all of the normal gcc options. We provide
> additional options targeted specifically at the Sun backend on SPARC as
> well.
What about GCC-style inline assembler? Does it work with the Studio
backend just the same as with the GCC backend?
George Vasick wrote:
> Darren J Moffat wrote:
>> So will all possible code that the GNU backend can build also be able
>> to be built with the Studio backend ?
>
> "all possible" is a pretty big claim. The answer is a qualified yes. We
> designed the product to be 100% compatible. There is alw
Garrett D'Amore wrote:
> Edward Pilatowicz wrote:
>> i'm not sure if this is an arc issue or not, but i'll raise it here
>> anyway. (perhaps it's just lack of imagination on my part.)
>>
>> i'm really confused about the usage model for this device. first you
>> recommend that this device is a goo
This case has been marked closed approved.
Cheers,
Jim
This case has no unresolved issues and nominally timed out last week,
although with the holidays there was no meeting.
If there are any outstanding issues please raise before or during the
LSARC meeting tomorrow otherwise we can review & close the case then.
--
Jyri J. Virkki - jyri.virkki at
I'll do so.
On Nov 30, 2009, at 1:48 PM, James Carlson wrote:
>> Function Specification provides detailed information on the stack.
>>
>> http://wikihome.sfbay.sun.com/TelcoVertical/attach/Diameter%2Fdiameter_fsd.odt
>
> If that is or contains normative architectural information, then
Kyle McDonald wrote:
> Garrett D'Amore wrote:
>> Edward Pilatowicz wrote:
>>> i'm not sure if this is an arc issue or not, but i'll raise it here
>>> anyway. (perhaps it's just lack of imagination on my part.)
>>>
>>> i'm really confused about the usage model for this device. first you
>>> recomm
I'm filing the following self-reviewed case on behalf of Cathy Zhou. It
is marked closed approved automatic. This case modifies 2009/388 which
has a Patch release binding and has not yet been included in a Patch
release. This case also has Patch release binding to allow the VRRP
functionality to
Lloyd L. Chambers wrote:
> Sun Diameter stack is an implementation of Diameter base protocol(RFC
> 3588)
> intended to provide an Authentication,Authorization and Accounting(AAA)
> framework
> for Network access or IP mobility applications running on Sun GlassFish
> communicati
Edward Pilatowicz wrote:
> i'm not sure if this is an arc issue or not, but i'll raise it here
> anyway. (perhaps it's just lack of imagination on my part.)
>
> i'm really confused about the usage model for this device. first you
> recommend that this device is a good choice as a ZFS SLOG. ok.
On Mon, Nov 30, 2009 at 01:59:25PM -0800, Alan Coopersmith wrote:
> Scott Rotondo wrote:
> > Part of the problem seems to be that there is no good place to keep the
> > source code. The choices seem to be:
> >
> > (a) Keep the source in an unknown, uncontrolled location (e.g. someone's
> > home
On Mon, Nov 30, 2009 at 01:51:36PM -0800, Scott Rotondo wrote:
> I agree that it would be better to integrate these FOSS "familiarity"
> packages in /contrib, at least initially. It would be a more accurate
> portrayal of what people are actually getting from us.
>
> Part of the problem seems to
i'm not sure if this is an arc issue or not, but i'll raise it here
anyway. (perhaps it's just lack of imagination on my part.)
i'm really confused about the usage model for this device. first you
recommend that this device is a good choice as a ZFS SLOG. ok. (i
guess that assumes you've hooke
Scott Rotondo wrote:
> Part of the problem seems to be that there is no good place to keep the
> source code. The choices seem to be:
>
> (a) Keep the source in an unknown, uncontrolled location (e.g. someone's home
> directory)
Sources in someone's home directory can't be used for /contrib, s
Nicolas Williams wrote:
>> I understand what de-railing means. I'm reacting mostly to the
>> withdrawal of the case. But also, when it comes to FOSS, the ARC can't
>> be de-railing too often, else the process will be unbearable, which is
>> partly why I asked if it wouldn't be better if all non-c
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
GNOME 2.28 Addendum
1.2. Name of Document Author/Supplier:
Author: Brian Cameron
1.3 Date of This Document:
Darren J Moffat wrote:
> So will all possible code that the GNU backend can build also be able to
> be built with the Studio backend ?
"all possible" is a pretty big claim. The answer is a qualified yes.
We designed the product to be 100% compatible. There is always a chance
somebody will fin
Bart Smaalders wrote:
> Bart Smaalders wrote:
>
>> If I use generic gcc for sparc and type ggc -c --help, I get a bunch
>> of output describing options that are interpreted by various stages
>> in the compilation and linking pipeline. Is any of this output
>> different w/ your code in place? In
I am sponsoring this case on behalf of Erwin Tsaur. The case seeks
patch binding for a Solaris 10 Update Release. Given that this case
merely carves out more FMA namespace and is supported by an approved
FMA portfolio, I consider it appropriate for self-review. If there is
disagreement, let me k
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Sun Diameter 1.0
1.2. Name of Document Author/Supplier:
Author: Venugopal RaoK
1.3 Date of This Document:
(cleaned up version)
The case materials have been updated (diff files showing the
changes are included).
This case has received three +1s and the timeout has expired.
I plan to mark this case closed approved at the end of the day.
Cheers,
Jim
The case materials have been updated (diff files showing the
changes have been included).
This case has received three +1s and the timeout has expired.
I plan mark this case closed approved at the end of the day.
Cheers,
Jim
This case, having a +1, and timing out with apparent consensus, is
closed approved.
- Garrett
Alan Coopersmith wrote:
> Garrett D'Amore - sun microsystems wrote:
>
>> The "bd" driver will be used as a block-oriented device driver for devices
>> that need general block device support.
>> Because we might in the future like to offers support for some of
>> these storage adapters on Solaris
25 matches
Mail list logo
