Tim Haley wrote:
I am sponsoring the following fast-track for myself. This case
introduces additional zpool sub-command options to support pool
recovery. The case is requesting micro/patch binding. Timeout is
09/16/2009.
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This
Rich.Brown at sun.com wrote:
[snip]
== Introduction/Background ==
Zero-copy (copy avoidance) is essentially buffer sharing
among multiple modules that pass data between the modules.
This proposal avoids the data copy in the READ/WRITE path
of filesystems, by providing a mechanism to
On 09/09/09 17:08, Garrett D'Amore wrote:
I've not had time to go over all this yet, but do we really believe this
kind of change is fast track appropriate? I have a feeling that this is
a significant enough core change with implications for a variety of
project teams, that maybe this one
On Wed, 2009-09-09 at 21:40 -0600, Tim Haley wrote:
I am sponsoring the following fast-track for myself. This case
introduces additional zpool sub-command options to support pool
recovery. The case is requesting micro/patch binding. Timeout is
09/16/2009.
+1
-Seb
Hi Roland,
Roland Mainz wrote:
[snip]
How do you handle sparse files, e.g. files with one or more holes ?
Sparse files are not handled any differently in VOP_READ/VOP_WRITE calls
when using the zero-copy interface. Modules that want to seek/skip holes
can use the
Mahesh Siddheshwar wrote:
Roland Mainz wrote:
[snip]
How do you handle sparse files, e.g. files with one or more holes ?
Sparse files are not handled any differently in VOP_READ/VOP_WRITE calls
when using the zero-copy interface. Modules that want to seek/skip holes
can use the
On Thu, Sep 10, 2009 at 07:25:32PM +0200, Roland Mainz wrote:
Mahesh Siddheshwar wrote:
If future enhancements are needed to extend xuio_t, a new xuio_type
can be defined and extended that way. For extensions not specific
to xuio, there also exists uio_extflg in the uio_t. Without a
This case looks orphaned. Can it simply be closed withdrawn? (Although
the 1-pager states the prototype for the project is complete.)
- Garrett
It appears that this case was submitted as a 1-pager instead of a
fast-track, and subsequently abandoned. Project team, do you still want
to keep this case alive? Would you like to turn it into a fast track?
(This is probably a non-controversial fast track for FOSS inclusion)
Or if
I am sponsoring this case for Jack Meng. It requests a minor binding and he
ONNV consolidation. I have marked it automatic, but am happy to start a timer
if an ARC member requests.
-- mark
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
I am sponsoring this case for Manjunath Basappa. It requests minor binding and
times out next Thursday.
-- mark
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:
Python
Stephen, Thanks!!
LSARC,
With Gary's issues clarified can someone +1 this project?
Thanks,
John
Stephen Browne wrote:
John,
Sorry I didn't realise that further discussion with Gary was off list.
I believe Gary's concerns have been addressed, His main
misunderstanding was in the
Mark Carlson wrote:
Dependencies
SUNWpython {Python core package, already available on opensolaris }
- This is must have dependency.
SUNWcherry-python {Web framework for Python, available on opensolaris }
- Routes can work with other web frameworks as well,
http://www.opensolaris.org/os/community/arc/announcements/
OpenSolaris ARC Agenda
TELECONFERENCE NUMBERS:
(866)545-5223 (Within US)
(215) 446-3661 (International)
ACCESS CODE 939-55-86
Times are US/Pacific Timezone
ARC meetings are recorded.
09/15/2009
10 min Open ARC Business
Bart Smaalders wrote:
Mark Carlson wrote:
Such a bootpath is not available from OBP, and also Solaris is
unable to
make up one for,
1) Different disk drivers, 'sd' or 'ssd' can be attached to an
iSCSI disk
2) Different TPGT can be used to access the boot
I am sponsoring this fast-track for myself, with a timeout of Sept. 17,
and a release binding of patch (though delivery is only planned for
OpenSolaris Solaris Next at this time).
This case is submitted to PSARC, as the traditional arbiter of the Solaris
filesystem layout, but cc'ed to LSARC,
ATTRIBUTES
See attributes(5) for description of the following attributes:
_
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_|_ ___|
|
With Gary's issues clarified can someone +1 this project?
My last comment was really just a nit, so +1.
Gary..
Once getting past the initial shock (okay, I've lived with /usr/X11 for
a *really* long time now!), the case seems straight-forward and
obvious. +1.
- Garrett
Alan Coopersmith wrote:
I am sponsoring this fast-track for myself, with a timeout of Sept. 17,
and a release binding of patch
Martin Bochnig wrote:
I guess only the pkgdefs will be changed?
Yes.
Or are there plans to one
day incorporate xwin into the OS/Net consolidation gate? Probably not.
Not even remotely considering it, but that's completely unrelated -
there's already many consolidations delivering files to
Martin Bochnig wrote:
I thought of it only because of Moinaks auto-builder (and my own
insufficient steps towards that direction a year ago).
Not combining consolidations for development purposes, just for
allowing external distributors to build _everything_ in one rush,
without interaction
With that I am closing this case as approved.
Thanks,
John
Gary Winiger wrote:
With Gary's issues clarified can someone +1 this project?
My last comment was really just a nit, so +1.
Gary..
Martin Bochnig wrote:
Wouldnt it be cheaper if all used the same?
Not after the huge cleaning bill we'd have to pay to clean up all the
blood spilled in the spec files vs. ON-style makefiles deathmatch
trying to decide which one to use, and the years of effort converting
all the other
Mark Carlson wrote:
Such a bootpath is not available from OBP, and also Solaris is unable to
make up one for,
1) Different disk drivers, 'sd' or 'ssd' can be attached to an
iSCSI disk
2) Different TPGT can be used to access the boot disk
Martin Bochnig wrote:
Every consolidation generates packages individually and just delivers
them into a spool area?
yes.
Is there no automated A-to-Z tool, that compiles everything at once
and then automatically combines the binary packages into a distro via
distro-constructor (or in the
+1 with one minor question:
On Thu, 2009-09-10 at 14:55 -0700, Alan Coopersmith wrote:
Specifically, the major directory mappings will be:
Previous location:New location:
/usr/X11/bin /usr/bin
/usr/X11/demo
And as for the limitations you mentioned: Thanks for this detailed summary.
Although: Different needs could also be addressed by a single system
In developing a distributed development system, one could use a
one-size-fits-all approach, or one could step back and define the high
level
Manjunath Basappa wrote:
I will list the following dependencies:
SUNWPython at 2.4.4,5.11-0.111:20090508T152730Z
SUNWPython26 at 2.6.1,5.11-0.111:20090508T152901Z
SUNWpython-cherrypy at 3.1.1,5.11-0.111:20090508T163103Z
Sounds good, though a) I'm not sure what the ARC will think of
Manjunath Basappa wrote:
Danek,
Thanks for your feedback.
One thing, I just installed latest OSOL (2009.06) and it does
have cherrypy! And it does appear in the /release repository
as well
(http://pkg.opensolaris.org/release/en/search.shtml?token=pythonaction=Search).
Wonder how it
I'm submitting this fast-track with Solaris minor binding, scheduled to
timeout at 09/18/2009. I think the one pager explains the case for a
re-integration of this library. API info is put into materials directory.
Thanks,
Suresh
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This
30 matches
Mail list logo
