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 10, we are
This case, having a +1, and timing out with apparent consensus, is
closed approved.
- Garrett
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
(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
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
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 what way?
George Vasick George.Vasick at sun.com 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
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 find a
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 always a
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:
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:
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
communication
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-core
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, since
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 be
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 directory)
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
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
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
recommend that this
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 it
This case has been marked closed approved.
Cheers,
Jim
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.
Part of
22 matches
Mail list logo
