Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
On Tue, 08 Sep 2009 10:55:57 -0700 Garrett D'Amore gdamore at sun.com wrote: James Carlson wrote: Given that, I'd actually prefer to remove the queue.h interfaces, and promote list.h. list.h interfaces are safer than BSD queue.h (see above argument), and have been around and available since ~forever. Please don't! The BSD queue.h interfaces are used in both kernel *and* user-space code -- they're also present on Linux -- and the lack of them on classic Solaris is a very annoying application portability issue. Removing them would be a big step backwards. Ok. Well in this case, someone else should raise the commitment level and ARC them. Just having them appear on Solaris without any ARC coverage or interface stability is IMO less than helpful. It looks like this arrived with the Packet Filter Hooks stuff. Correct: 6418698 PSARC/2005/334 - Packet Filtering Hooks API (not introduced by fwflash at all, I just used what was already there) James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
Fast reboot support of GNOME restart dialog [LSARC/2009/454 FastTrack timeout 09/01/2009]
Hi all, Please see my comments in line. On Tue, 2009-09-08 at 18:56 -0500, Brian Cameron wrote: Note that I changed the IAM file for this case to waiting need spec and I increased the timeout to 09/15/2009. In what timeframe does the project team plan to provide an updated one-pager to describe how they plan to address the issues raised in the discussion so far? I just sent a mail to ConsoleKit community about how to extend it to make it support fast reboot. I plan to update the proposal when we have a clear solution. Issues raised in discussion that should be addressed by an updated onepager include: 1) Darren Moffat says that the proposed solution requires that a temporary property needs to be created in an SMF service and that requires a different (considerably more powerful) authorisation than the one to reboot. He points out that the solution to this problem is likely outside of the scope of this case, so that the project team probably needs to work with the team that introduced the fast reboot functionality to determine the proper solution for this before moving forward. For reference, CR #6878412 was filed about this issue. Yes, the temporary smf property is beyond my control but I will discuss this with Sherry. 2) There has been some discussion about whether ConsoleKit is the correct interface to use for supporting shut down and reboot on Solaris. For example, Joerg Barfurth had this comment: ConsoleKit manages Seats and Sessions and their association to devices and X servers. Interfaces for system power control are really something different and would really be better offered by a separate power management service. So, I think it would be helpful to clarify the pros and cons of the various options (e.g. using HAL, using ConsoleKit, using a new separate power management service), and explain why whatever is decided to be the solution is the best approach. The basic idea is to follow the community. Now that the community implement reboot/shutdown in HAL/ConsoleKit, I think it's reasonable to also implement fast reboot in one of them. And because HAL is deprecated, ConsoleKit is a better choice. As for a separate power management service, currently there is devicekit-power (It will replace the power management part in HAL) but 1) community does not implement reboot/shutdown in it 2) it has not been integrated into Solaris yet. We also definitely do not want to maintain a private such service. So according to above reasons, ConsoleKit is chosen. Note that if it is necessary to enhance ConsoleKit interfaces to support this feature, that any changed ConsoleKit interfaces will also need to be ARC'ed. Perhaps any such needed changes to the ConsoleKit specification could be included as a part of this case? Also, note that although ConsoleKit is currently targeting build 128, that there is some risk that ConsoleKit might slip if the requirements set in the ConsoleKit ARC case are not finished (e.g. MultiSeat support) in time for planned integration in build 128. While I am hopeful that the ConsoleKit integration will not slip, I recommend that the project team have a Plan B if it is necessary to avoid slippage if the ConsoleKit project slips. I have considered this problem. I will not integrate my case before ConsoleKit's integration. Regards, Jedy Brian
LSARC/2009/472 - Crypt::CBC Perl Module
Thank you .. Spoorthy John Fischer wrote: All, This case was approved today at LSARC during the business portion of the meeting. John Spoorthy H.S wrote: Hi John, Here's the new ARC one pager for the package Crypt-CBC. Thanks Spoorthy John Fischer wrote: Sure. John Spoorthy H.S wrote: Fine with it. I will change these in packaging also. John, Should I send the new ARC one pager with these modifications ? Or you give any suggestions if you have. Thanks Spoorthy Mark Phalan wrote: On Wed, 2009-09-02 at 16:13 +0530, Spoorthy H.S wrote: Mark Phalan wrote: On Wed, 2009-09-02 at 14:55 +0530, Spoorthy H.S wrote: ... I am installing it onto usr/perl5/vendor_perl/5.8.4/crypt-cbc. I'm not a Perl expert but that still looks wrong to me: Shouldn't the path look something like this? usr/perl5/vendor_perl/5.8.4/Crypt/CBC.pm FYI: On snv_120 $ perl -e 'print @INC\n' /usr/perl5/5.8.4/lib/i86pc-solaris-64int /usr/perl5/5.8.4/lib /usr/perl5/site_perl/5.8.4/i86pc-solaris-64int /usr/perl5/site_perl/5.8.4 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.8.4/i86pc-solaris-64int /usr/perl5/vendor_perl/5.8.4 /usr/perl5/vendor_perl . Anyway, the user shouldn't have to do anything special to use this module other than specifying something like 'use Crypt::CBC' So, what will be the path for this ? If its usr/perl5/vendor_perl/5.8.4/i86pc-solaris-64int, I will update the ARC one pager. I think CBC.pm should be installed as usr/perl5/vendor_perl/5.8.4/Crypt/CBC.pm So the path is usr/perl5/vendor_perl/5.8.4/Crypt instead of usr/perl5/vendor_perl/5.8.4/crypt-cbc ? Yes. ... The dependency is mentioned in the ARC one pager as *Dependencies SUNWperl-crypt-des [ This package development is under progress ] * Ok. ... It sounds like its part of the build system for the Perl module. It shouldn't be part of the installation. Hmm ... Thanks for the suggestion. But, I feel this file is required. I am doing perl Makefile.PL in the my_ws/usr/src/lib/perl-crypt-cbc/Makefile.sfw. This generates the required files to be kept like man page. Right. But that file should not be delivered in the package that is installed on end-users machines. -M
Label Builder CLI [LSARC/2009/457 FastTrack timeout 08/31/2009]
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 term dialog. I was always referring to a GUI dialog box and Gary appears to have thought I was taking about a CLI dialogue between the system and the CLI user. I will summarise the responses below. On 09/08/09 18:11, John Fischer wrote: Stephen, Can you address Gary's issues? I have extended the timer to this Friday, September 11th. Thanks, John Gary Winiger wrote: I have placed the attached man page document in the case directory under the materials subdirectory. For the record from a private thread with the project team: My primary comment on the man page and case all together is that it's unclear what the output of call to the CLI is. Is it a single label, a dimming list (from the contracted project private interfaces), a construction of all labels between min and max, in which case what does the default have to do with it. It is a single label. The default is specified to indicate the default label selection should the user simply hit OK on the dialog box without further interaction. Also the man page doesn't say what context (global zone, sys_trans_label, ...) is needed? Agreed to update manpage. txselectlabel - label selection dialog utility It's unclear to me how this utility presents a dialogue with the user. This is the source of Gary's confusion. It is a GUI dialog box not a CLI only conversation 'dialogue'. EXIT STATUS The following exit values are returned: 0 A label was successfully selected 1 Missing or ivalid command argument(s) 2 A label translation error occured Is there something more here? str_to_label gives a pointer to what part of the string was in error. Is something spit out to stderr? As stated in the proposal, appropriate error messages will printed to stderr. 5 Dialog was canceled without selecting a label It's unclear what dialogue is taking place. More information would be useful. more confusion. Gary now knows this is a GTK GUI dialog complete with a cancel button. FILES The following files are used by this utility: /usr/bin/txselectlabelThe command-line executable ATTRIBUTES See attributes(5) for description of the following attributes: _ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_|_ ___| | Availability| SUNWtgnome-tsol-libs| |_|_| | Interface stability | Uncommitted | |_|_| The output from the command should probably be Not An Interface Calling scripts will rely on both the printed string for the selected label and the exit status so this very much needs to be an interface. Stephen. Gary..
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
Garrett D'Amore wrote: My brief comments: 1) We need a list API. Agreed. 2) I'm of the opinion that having multiple APIs in the DDI to accomplish the same thing is not constructive. It's certainly suboptimal. But where there are two or more important and conflicting traditions, what do you do? 3) sys/queue.h should never have been delivered in SUNWhea without a supporting ARC case. (But then neither should have sys/list.h.) I disagree with that assertion. The contents of SUNWhea is not itself a documented interface -- in other words, what determines stability level is system documentation (man pages), and not what package delivers something or where it appears in the file system. We have historically shipped a mix of public and private interfaces via SUNWhea. Long ago, I filed a CR (forget the number) that suggested breaking up SUNWhea (and the SUNWarc* and perhaps other) package into public and private bits, so that we could install only public interfaces by default, and exclude private ones from accidental discovery. (Obviously, users who need to can always install the private packages; we'd still ship them -- perhaps with even more things included -- but just not install by default.) Think of it as linker mapfiles for packaging. The idea, unfortunately, went nowhere. Too many people were either skeptical of the utility of breaking up SUNWhea or of the value of trying to segregate private interfaces better. In this case, sys/list.h was Consolidation Private and sys/queue.h was (apparently) intended as Project Private but somehow used as though it were Consolidation Private. In any event, those sorts of interfaces do not *necessarily* need ARC review. Though I agree that some ARC review would have been better than not having it at all. 5) If a Member feels that sys/queue.h is preferable to sys/list.h, then I think that Member should derail this case (at which point I'll probably just withdraw it) and then we can try to identify a list interface that is best suited for the DDI. No longer a member, but I think that completely misses the point. The point is: - go ahead and add stable support for sys/list.h; we need it. - leave sys/queue.h where it is; the world needs it. - someone (not necessarily you) should provide a case that documents sys/queue.h, because it clearly slipped through the process cracks. - these things are unrelated. Really. -- James Carlson 42.703N 71.076W carlsonj at workingcode.com
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
James Carlson wrote: 3) sys/queue.h should never have been delivered in SUNWhea without a supporting ARC case. (But then neither should have sys/list.h.) I disagree with that assertion. The contents of SUNWhea is not itself a documented interface -- in other words, what determines stability level is system documentation (man pages), and not what package delivers something or where it appears in the file system. We have historically shipped a mix of public and private interfaces via SUNWhea. Long ago, I filed a CR (forget the number) that suggested breaking up SUNWhea (and the SUNWarc* and perhaps other) package into public and private bits, so that we could install only public interfaces by default, and exclude private ones from accidental discovery. (Obviously, users who need to can always install the private packages; we'd still ship them -- perhaps with even more things included -- but just not install by default.) Think of it as linker mapfiles for packaging. The idea, unfortunately, went nowhere. Too many people were either skeptical of the utility of breaking up SUNWhea or of the value of trying to segregate private interfaces better. I'm not of the opinion that breaking up SUNWhea into smaller packages is useful. I *am* of the opinion that headers which are Project Private, or possibly Consolidation Private, should not be packaged at all. (I'd probably grant a special exception for Consolidation Private interfaces which are *intended* for public consumption at some future date, but even that could probably just as easily be dealt with by a future push after ARC approves the interfaces for public consumption.) I suppose at one point having those headers on the system was useful for debugging back when people had to manually work out structures in adb. These days with CTF they are completely unnecessary. Whenever I easily I can, I remove project private (especially *driver private!*) headers from packaging. -- Garrett
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
I suppose at one point having those headers on the system was useful for debugging back when people had to manually work out structures in adb. These days with CTF they are completely unnecessary. Whenever I easily I can, I remove project private (especially *driver private!*) headers from packaging. There's still: pidentd, lsof. Casper
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
On Wed, Sep 09, 2009 at 08:53:22AM -0700, Garrett D'Amore wrote: I'm not of the opinion that breaking up SUNWhea into smaller packages is useful. I *am* of the opinion that headers which are Project Private, or possibly Consolidation Private, should not be packaged at all. (I'd probably grant a special exception for Consolidation Private interfaces which are *intended* for public consumption at some future date, but even that could probably just as easily be dealt with by a future push after ARC approves the interfaces for public consumption.) Before OpenSolaris those private headers were quite useful to customers by hinting at implementation details that help observe the system. Now customers have source. If they want to use private interfaces, they will. Shipping or not shipping such headers is not terribly important, but documenting the Public interfaces and putting a warning in the private headers is. I suppose at one point having those headers on the system was useful for debugging back when people had to manually work out structures in adb. Among other things. These days with CTF they are completely unnecessary. Whenever I easily CTF doesn't capture C pre-processor #defines. CTF doesn't capture extern function prototypes. CTF is not a replacement for shipping header files -- CTF really has nothing to do with shipping or not shipping private headers. Nico --
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
Garrett D'Amore wrote: James Carlson wrote: Think of it as linker mapfiles for packaging. The idea, unfortunately, went nowhere. Too many people were either skeptical of the utility of breaking up SUNWhea or of the value of trying to segregate private interfaces better. I'm not of the opinion that breaking up SUNWhea into smaller packages is useful. I *am* of the opinion that headers which are Project Private, or possibly Consolidation Private, should not be packaged at all. (I'd probably grant a special exception for Consolidation Private interfaces which are *intended* for public consumption at some future date, but even that could probably just as easily be dealt with by a future push after ARC approves the interfaces for public consumption.) That's not how Sun has done things historically. Things are added to SUNWhea on project team whim. Sometimes headers that have nothing to do with anything at all (net/af.h, anyone?) are delivered. Sometimes things that include private implementation details are there. It's a potpourri. The point of architecture isn't (and hasn't been) to keep secrets; it's to define what should and should not be used as a matter of _documentation_. The distinction is important. Finding a random file on the system doesn't give you any special guarantee that the contents won't blind you or drive you mad. Read through CR 4696464 for some of the history on this. I suppose at one point having those headers on the system was useful for debugging back when people had to manually work out structures in adb. These days with CTF they are completely unnecessary. Whenever I easily I can, I remove project private (especially *driver private!*) headers from packaging. I think you're at least partly swimming against the tide. I agree that it'd be nice to have some clearer delineation, but outright removal isn't quite the norm. Only omitting *documentation* has been the norm. One other important use, besides adb, is for third party software that (knowingly or not) violates the undocumented interfaces. This is unfortunately extremely common, simply because the set of documented interfaces is a subset of the *NECESSARY* ones. And when faced with delivering a product for revenue versus obeying obscure architectural advice from Sun, guess which one wins? The system is unfortunately rife with this sort of stuff. The VM/VFS interfaces are just the tip of the iceberg. -- James Carlson 42.703N 71.076W carlsonj at workingcode.com
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
Garrett D'Amore wrote: These days with CTF they are completely unnecessary. CTF is Consolidation Private, and only available to things built in the ON consolidation, so it's not a useful replacement for anything. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
COMSTAR ALUA active/standby support [PSARC/2009/465 FastTrack timeout 09/02/2009]
The timer on this case had been extended to 9/09/2009 and was approved at PSARC today. - John
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
Alan Coopersmith wrote: Garrett D'Amore wrote: These days with CTF they are completely unnecessary. CTF is Consolidation Private, and only available to things built in the ON consolidation, so it's not a useful replacement for anything. The drivers that are built in ON don't need to expose their header files, though. For example, what use is exposing a header file for afe? Approximately zero. So its not delivered. If you want to look at the internals, grab the full source code, instead of just a header file If you want to try to debug it, you can still use macros like $afe in kmdb, thanks to CTF. - Garrett
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
On Wed, 2009-09-09 at 11:03 -0700, Garrett D'Amore wrote: Alan Coopersmith wrote: Garrett D'Amore wrote: These days with CTF they are completely unnecessary. CTF is Consolidation Private, and only available to things built in the ON consolidation, so it's not a useful replacement for anything. The drivers that are built in ON don't need to expose their header files, though. For example, what use is exposing a header file for afe? Approximately zero. So its not delivered. If you want to look at the internals, grab the full source code, instead of just a header file If you want to try to debug it, you can still use macros like $afe in kmdb, thanks to CTF. This is a riveting debate, but at this point, it has little relevance to this case. This case has its +1 (and I'll add my own +1 now), and we're all in agreement that the existence of sys/queue.h shouldn't affect this case as it stands. Let's move on please and have the philosophical header file discussion over at arc-discuss. -Seb
daemon() in libc [PSARC/2009/444 FastTrack timeout 08/24/2009]
This case was approved at PSARC on the 2nd of September, 2009. Darren
Updating the IAM file for opinions
Reviewing the file status.allowed for guidance on how to update the IAM file for a case, it seems to stop being useful once a case gets to the opinion review stage. Below is a proposed patch to the status.allowed file to make it more complete. Darren --- status.allowed --- *** /tmp/sccs.eLaGnyWed Sep 9 11:32:22 2009 --- status.allowed Wed Sep 9 11:32:00 2009 *** *** 119,124 --- 119,126 waiting need spec( MM/DD/)? waiting need vote MM/DD/ waiting need( draft)? opinion( MM/DD/)? + # when the opinion is ready to be submitted, see the comments + # below for waiting PSARC review. waiting ALL review MM/DD/ # Covers both ... *ARC... as well as ... SAC... review cycles closed approved MM/DD/ *** *** 154,156 --- 156,181 closed grandfathered closed hole # Unknown... + + waiting PSARC review MM/DD/ + # a minium of 7 days is required for the review by PSARC + # of an opinion submitted. The opinion should be sent by + # email to PSARC. If written using the nroff template, + # use nroffit to format the opinion appropriately. + # After allowing time for PSARC review and including any + # feedback, it is then eligable for SAC review. + waiting SAC review MM/DD/ + # a minium of 7 days is required for the review by SAC + # of an opinion submitted. The opinion should be sent by + # email to sac-review at sac. + # a minium of 7 days is required for the review by the SAC + # of an opinion submitted. The opinion should be sent by + # email to sac-review at sac. + # After allowing time for SAC review and including any + # feedback, it is then eligable for SAC review. + closed approved MM/DD/ + # After the integration of feedback from the members is + # complete, the opinion is then sent to sac-opinion at sac + # for archiving and to the relevant steering committee(s) + # (steeringcommittee-opinion at scs.eng -- for Solaris + # Foundation Steering Committee, it's sfsc-opinion at scs.eng).
OpenSolaris ARC Minutes - 09/08/2009
SYSTEM ARCHITECTURE COUNCIL Layered Software ARC - 09-08-2009 MEETING MINUTES Send CORRECTIONS, additions, deletions to lsarc-coord at sun.com. Minutes are archived in /shared/sac/Minutes/LSARC. ATTENDEES: Chair Mark CarlsonYes Members (8 active members) Lloyd Chambers no Aniruddh Dikhit no Danek Duvall(on sabbatical) John FischerYes Ed Hunter Yes Chris Kasso (on sabbatical) Arieh Markel(on sabbatical) Margot Miller Yes Jyri Virkki no Michael Kearney Yes Tom Childersno (external) Mark Martin no (external) Interns Brian Cameron Yes James Gates no Matthias Huetschno Linda Schneider no Rahul Shah no Krishna Tallapaneni no David Tong no James Walkerno Jeff Caino Coordinator Asa Romberger (PM) Yes Guest Not all names are captured. Please send email to Asa.Romberger at Sun.com, if you attended the meeting and your name was not captured. == AGENDA == Case Anchors: br == ARC Business Case (Timeout) Exposure Title 2009/454 (09/01/09) open Fast reboot support of GNOME restart dialog waiting needs spec 2009/457 (08/31/09) open Label Builder CLI extend timer to 09/10 2009/460 (08/31/09) open This is a test should be marked closed withdrawn 2009/469 (09/08/09) open Gutenprint Ver 5.2.4 to be discussed at next week's meeting 2009/472 (09/04/09) open Crypt-CBC Perl Module approved 2009/475 (09/15/09) open GNOME 2.28 let it run Opinions Other stuff --- Need owners to two new cases - Mark to find them Next Meeting -- 09/15/2009 10 min Open ARC Business 10 min Open Discussion of 2009/469 GutenPrint Ver 5.2.4 10 min Closed ARC Business
OpenSolaris ARC Minutes - 09/09/2009
SYSTEM ARCHITECTURE COUNCIL Platform Software ARC - PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 09-09-2009 MEETING MINUTES Send CORRECTIONS, additions, deletions to psarc-coord at sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. Co-Chair(s): Garrett D'Amore:Yes Tim Marsland: no ATTENDEES - Members: (6 active members) Kais Belgaied: Yes Mark Carlson: Yes Richard Matthews: no Darren Moffat: no (on sabbatical) Sebastien Roy: Yes Glenn Skinner: Yes Bill Sommerfeld:no (on sabbatical) Gary Winiger: no (on sabbatical) STAFF - Asa Romberger (PM): Yes ATTENDEES - Interns: Frank Che no James Falkner: no (on sabbatical) Daniel Hain:Yes Michael Haines: no Alan Hargreaves:no Phil Harman:no Wyllys Ingersoll: no Darren Reed:Yes Dean Roehrich no Ienup Sung: no Phi Tranno Brian Utterback:no James WalkerYes Suhasini PeddadaYes Calum Mackayno Mark Martin no (external) Don Cragun Yes (external) Guests: -- GUESTS -- Nicholas Droux John Forte Kevin Song Scott Rotondo Not all names are captured. Please send email to Asa.Romberger at Sun.com, if you attended the meeting and your name is missing from the list. --- MEETING SUMMARY: AGENDA 09/09/2009 10:00-10:10 Open ARC Business (use open dial in above) 10:15-10:25 Closed ARC Business (use closed dial in above) 10:25-11:10 Closed Inception: Public GLDv3 Interfaces (2009/473) Submitter: Nicolas Droux Owner: Kais Belgaied Exposure: closed --- Case Anchors: br === Fast Tracks: Case (Timeout) Exposure Title 2009/396 (09/09/09) open Tickless Kernel Architecture / lbolt decoupling 2009/444 (08/24/09) open daemon() in libc 2009/455 (08/28/09) open Environment Modules 2009/465 (09/09/09) open COMSTAR ALUA active/standby support 2009/476 (09/15/09) open Public linked lists 2009/477 (09/15/09) open Addition of NE_IFINDEX_CHANGE to sys/neti.h Next Meeting: = 09/16/2009 10:00-10:10 Open ARC Business (use open dial in above) 10:10-10:55 AVAILABLE 11:00-11:10 Closed ARC Business (use closed dial in above)
PSARC/2007/596 contract for SFW trilld to use ON bridging interfaces
Sharon, Please reply-all to this mail to indicate that you approve of this contract (you represent both the supplier and the consumer) as required by PSARC/2007 596 RBridges: Routing Bridges. The contract file is attached for you to review, and also located in the case directory as contract-01. -Seb -- next part -- @(#)contract1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2007/596-01 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris Consolidation: OS/Net Department or Group: Solaris Networking Bugster Product/Category/SubCategory: solaris/network/bridging Responsible Manager: Sharon Liu 3. The CONSUMER is identified by the following: Product or Bundle: Solaris Consolidation: SFW Department or Group: Solaris Networking Bugster Product/Category/SubCategory: solaris/network/bridging Responsible Manager: Sharon Liu 4. The INTERFACES are: Library: libdladm.so.1 Consolidation Private Header files: libdladm.hConsolidation Private libdllink.h Consolidation Private libdlbridge.h Consolidation Private libdlvlan.h Consolidation Private net/bridge.h Project Private net/trill.h Project Private Macros: AF_TRILLProject Private ALL_ISIS_RBRIDGES Project Private BRIDGE_GROUP_ADDRESSProject Private DATALINK_ANY_MEDIATYPE Consolidation Private DATALINK_CLASS_ALL Consolidation Private DATALINK_CLASS_VLAN Consolidation Private DLADM_OPT_ACTIVEConsolidation Private DLADM_PROP_VAL_PERSISTENT Consolidation Private DLADM_STATUS_OK Consolidation Private DLADM_STRSIZE Consolidation Private DLADM_WALK_CONTINUE Consolidation Private PF_TRILLProject Private RBRIDGE_NICKNAME_MAXProject Private RBRIDGE_NICKNAME_MINProject Private RBRIDGE_NICKNAME_MINRES Project Private RBRIDGE_NICKNAME_NONE Project Private RBRIDGE_NICKNAME_UNUSED Project Private TNI_ADJNICK Project Private TNI_DTROOTNICK Project Private TNI_VLANFILTERMAP Project Private TRILL_TCI_BPDU Project Private Ioctls: TRILL_ADDNICK Project Private TRILL_DELALLProject Private TRILL_DESIGVLAN Project Private TRILL_GETMTUProject Private TRILL_HWADDRProject Private TRILL_NEWBRIDGE Project Private TRILL_NICKFLUSH Project Private TRILL_PORTFLUSH Project Private TRILL_SETNICK Project Private TRILL_TREEROOT Project Private TRILL_VLANFWDER Project Private Datatypes: datalink_class_tConsolidation Private datalink_id_t Consolidation Private dladm_conf_tConsolidation Private dladm_handle_t Consolidation Private dladm_status_t Consolidation Private dladm_vlan_attr_t Consolidation Private trill_nickinfo_tProject Private Functions: dladm_bridge_get_nick Project Private dladm_bridge_getlinkProject Private dladm_bridge_set_nick Project Private dladm_close Consolidation Private dladm_datalink_id2info Consolidation Private dladm_destroy_conf Consolidation Private dladm_get_linkprop_values Consolidation Private dladm_open Consolidation Private dladm_read_conf Consolidation Private dladm_status2strConsolidation Private dladm_vlan_info Consolidation Private dladm_walk_datalink_id Consolidation Private 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing (Exporting) these INTERFACES is: 2006/499, 2007/596, 2008/055 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the
Opinion for PSARC review: 2007/596 RBridges: Routing Bridges
ARC members, please review and submit comments by 09/16/2009. sun microsystems Systems Architecture Committee _ Subject: RBridges: Routing Bridges Submitted by: James Carlson File: PSARC/2009/596/opinion.ms Date: June 17th, 2009 Committee: Sebastien Roy, James Carlson, Garrett D'Amore, Mark Martin, Richard Matthews. Product Approval Committee: Solaris PAC solaris-pac-opinion at sun.com 1. Summary This project builds upon Solaris Bridging as defined in PSARC 2008/055 to deliver a TRILL-based RBridging mechan- ism. 2. Decision Precedence Information The project is approved as specified in references [1-7]. The project may be delivered in a Patch release of Solaris. The project depends on the following other projects and may not be delivered before them: PSARC/2008/055 Solaris Bridging PSARC/2009/344 Bridging Updates PSARC/2008/352 IS-IS For OpenSolaris PSARC/2007/587 Volo -- Low Latency Socket Framework PSARC/2008/694 Volo Interfaces Amendment PSARC/2009/596 Copyright 2009 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. | Interfaces Exported | |__||__| |Interface | Classification| Comments| |__||__| |dladm create-bridge -P| Committed | [3] | |dladm modify-bridge -P| Committed | [3] | |TRILL | Uncommitted | References [4], [5], and [6]| |libdladm | Contracted Cons. Priv.| Used by trilld | |AF_TRILL | Contracted Proj. Priv.| Used by trilld | |net/trill.h | Contracted Proj. Priv.| Used by trilld | |/etc/sock2path| Committed | Entry for AF_TRILL | |/usr/sbin/trilld | Project Private | | |trill.xml SMF manifest| Project Private | | |kernel/socketmod/trill| Project Private | kernel TRILL module | |__||__| The project imports the following interfaces. ___ | Interfaces Imported | |__|___|__| |Interface | Classification | Comments| |__|___|__| |Nemo/GLDv3| Consolidation Private| PSARC 2004/571, 2006/357| |Volo | Consolidation Private| PSARC 2007/587, 2008/694| |__|___|__| 4. Opinion The project was approved with little discussion. Note that the trilld daemon delivered in the SFW consolidation uses Contracted Private interfaces from the ON consolidation, and a PSARC contract file [7] containing the terms of the con- tract is located in the case directory. 5. Minority Opinion(s) None. 6. Advisory Information None 7. Appendices PSARC/2009/596 Copyright 2009 Sun Microsystems - 3 - 7.1. Appendix A: Technical Changes Required None 7.2. Appendix B: Technical Changes Advised None 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2009/596/committed.materials. 1. RBridges Architecture File: rbridges-arch.png 2. PSARC 20 Questions File: rbridges-20q.txt 3. Draft dladm(1M) Man Page File: dladm-new.txt 4. Rbridges: Base Protocol Specification File: draft-ietf-trill-rbridge-protocol-12.txt 5. Rbridges: TRILL Header Options File: draft-eastlake-trill-rbridge-options-01.txt 6. RBridges: Use of IS-IS File: draft-eastlake-trill-rbridge-isis-02.txt 7. Contract for trilld use of Private Interfaces File (in base directory): contract-01 PSARC/2009/596 Copyright 2009 Sun Microsystems
Opinion for PSARC review: 2007/596 RBridges: Routing Bridges
Looks OK to me. - Garrett Sebastien Roy wrote: ARC members, please review and submit comments by 09/16/2009. sun microsystems Systems Architecture Committee _ Subject: RBridges: Routing Bridges Submitted by: James Carlson File: PSARC/2009/596/opinion.ms Date: June 17th, 2009 Committee: Sebastien Roy, James Carlson, Garrett D'Amore, Mark Martin, Richard Matthews. Product Approval Committee: Solaris PAC solaris-pac-opinion at sun.com 1. Summary This project builds upon Solaris Bridging as defined in PSARC 2008/055 to deliver a TRILL-based RBridging mechan- ism. 2. Decision Precedence Information The project is approved as specified in references [1-7]. The project may be delivered in a Patch release of Solaris. The project depends on the following other projects and may not be delivered before them: PSARC/2008/055 Solaris Bridging PSARC/2009/344 Bridging Updates PSARC/2008/352 IS-IS For OpenSolaris PSARC/2007/587 Volo -- Low Latency Socket Framework PSARC/2008/694 Volo Interfaces Amendment PSARC/2009/596 Copyright 2009 Sun Microsystems - 2 - 3. Interfaces The project exports the following interfaces. | Interfaces Exported | |__||__| |Interface | Classification| Comments | |__||__| |dladm create-bridge -P| Committed | [3] | |dladm modify-bridge -P| Committed | [3] | |TRILL | Uncommitted | References [4], [5], and [6]| |libdladm | Contracted Cons. Priv.| Used by trilld | |AF_TRILL | Contracted Proj. Priv.| Used by trilld | |net/trill.h | Contracted Proj. Priv.| Used by trilld | |/etc/sock2path| Committed | Entry for AF_TRILL | |/usr/sbin/trilld | Project Private | | |trill.xml SMF manifest| Project Private | | |kernel/socketmod/trill| Project Private | kernel TRILL module | |__||__| The project imports the following interfaces. ___ | Interfaces Imported | |__|___|__| |Interface | Classification | Comments| |__|___|__| |Nemo/GLDv3| Consolidation Private| PSARC 2004/571, 2006/357| |Volo | Consolidation Private| PSARC 2007/587, 2008/694| |__|___|__| 4. Opinion The project was approved with little discussion. Note that the trilld daemon delivered in the SFW consolidation uses Contracted Private interfaces from the ON consolidation, and a PSARC contract file [7] containing the terms of the con- tract is located in the case directory. 5. Minority Opinion(s) None. 6. Advisory Information None 7. Appendices PSARC/2009/596 Copyright 2009 Sun Microsystems - 3 - 7.1. Appendix A: Technical Changes Required None 7.2. Appendix B: Technical Changes Advised None 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2009/596/committed.materials. 1. RBridges Architecture File: rbridges-arch.png 2. PSARC 20 Questions File: rbridges-20q.txt 3. Draft dladm(1M) Man Page File: dladm-new.txt 4. Rbridges: Base Protocol Specification File: draft-ietf-trill-rbridge-protocol-12.txt 5. Rbridges: TRILL Header Options File: draft-eastlake-trill-rbridge-options-01.txt 6. RBridges: Use of IS-IS File: draft-eastlake-trill-rbridge-isis-02.txt 7. Contract for trilld use of Private Interfaces File (in base directory): contract-01 PSARC/2009/596 Copyright 2009 Sun Microsystems
PSARC/2007/596 contract for SFW trilld to use ON bridging interfaces
On Wed, 2009-09-09 at 13:41 -0700, Sharon Liu wrote: Seb, Yes, I approve this contract. The contract is now valid and approved. Thank you, -Seb
Updating the IAM file for opinions
On Wed, Sep 9, 2009 at 11:37 AM, Darren Reed Darren.Reed at sun.com wrote: Reviewing the file status.allowed for guidance on how to update Most of this is already covered in the Member Handbook on sac.sfbay, in the section about opinion duties. The status.allowed is a memory reference, and not intended to be the only doc one needs. With that said, I don't see any problem with adding more comments/examples to it. -John
Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009]
I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli Zhang.
This case proposes new interfaces to support copy reduction in the I/O path
especially for file sharing services.
Minor binding is requested.
This times out on Wednesday, 16 September, 2009.
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:
Copy Reduction Interfaces
1.2. Name of Document Author/Supplier:
Author: Mahesh Siddheshwar, Chunli Zhang
1.3 Date of This Document:
09 September, 2009
4. Technical Description
== 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 share data buffers
between the modules. It is intended to be used by network file
sharing services like NFS, CIFS or others.
Although the buffer sharing can be achieved through a few different
solutions, any such solution must work with File Event Monitors
(FEM monitors)[1] installed on the files. The solution must
allow the underlying filesystem to maintain any existing file
range locking in the filesystem.
The proposed solution provides extensions to the existing VOP
interface to request and return buffers from a filesystem. The
buffers are then used with existing VOP_READ/VOP_WRITE calls with
minimal changes.
== Proposed Changes ==
VOP Extensions for Zero-Copy Support
a. Extended struct uio, xuio_t
The following proposes an extensible uio structure that can be extended for
multiple purposes. For example, an immediate extension, xu_zc, is to be
used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to pass loaned
zero-copy buffers, as well as to be passed to the existing VOP_READ/VOP_WRITE
calls for normal read/write operations. Another example of extension,
xu_aio, is intended to replace uioa_t for async I/O.
This new structure, xuio_t, contains the following:
- the existing uio structure (embedded) as the first member
- additional fields to support extensibility
- a union of all the defined extensions
The following uio_extflag is added to indicate that an uio structure is
indeed an xuio_t:
#define UIO_XUIO0x004 /* Structure is xuio_t */
The following uio_extflag will be removed after uioa_t has been converted
to xuio_t:
#define UIO_ASYNC 0x002 /* Structure is xuio_t */
The project team has commitment from the networking team to remove
the current use of uioa_t and use the proposed extensions (CR 6880095).
The definition of xuio_t is:
typedef struct xuio {
uio_t xu_uio; /* Embedded UIO structure */
/* Extended uio fields */
enum xuio_type xu_type; /* What kind of uio structure? */
union {
/* Async I/O Support */
struct {
uint32_t xu_a_state;/* state of async i/o */
uint32_t xu_a_state;/* state of async i/o */
ssize_t xu_a_mbytes;/* bytes that have been uioamove()ed */
uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */
void **xu_a_lppp; /* pointer into lcur-uioa_ppp[] */
void *xu_a_hwst[4]; /* opaque hardware state */
uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages */
} xu_aio;
/* Zero Copy Support */
struct {
enum uio_rw xu_zc_rw; /* the use of the buffer */
void *xu_zc_priv; /* fs specific */
} xu_zc;
} xu_ext;
} xuio_t;
where xu_type is currently defined as:
typedef enum xuio_type {
UIOTYPE_ASYNCIO,
UIOTYPE_ZEROCOPY
} xuio_type_t;
New uio extensions can be added by defining a new xuio_type_t, and adding a
new member to the xu_ext union.
b. Requesting zero-copy buffers
#define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \
fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct)
int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *,
caller_context_t *);
This function requests buffers associated with file vp in preparation for a
subsequent zero copy read or write. The extended uio_t -- xuio_t is used
to pass the parameters and results. Only the following fields of xuio_t are
relevant to this call.
uiozcp-xu_uio.uio_resid: used by the caller to specify the total length
of the buffer.
uiozcp-xu_uio.uio_loffset: Used by the caller to indicate the file offset
it would like the buffers to be associated with. A value of -1
indicates that the provider returns buffers that are not associated
with a particular offset. These are defined to be anonymous buffers.
Anonymous buffers may be used
PSARC/2007/596 contract for SFW trilld to use ON bridging interfaces
Seb, Yes, I approve this contract. Thanks, Sharon Sebastien Roy wrote: Sharon, Please reply-all to this mail to indicate that you approve of this contract (you represent both the supplier and the consumer) as required by PSARC/2007 596 RBridges: Routing Bridges. The contract file is attached for you to review, and also located in the case directory as contract-01. -Seb
Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009]
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 ought to be a full case. I'd be a
bit uncomfortable allowing this one to just time out with a single +1,
which is the normal rule for fast tracks.
Am I alone in this particular concern?
Are there any implications for unbundled 3rd party filesystems?
- Garrett
Rich.Brown at Sun.COM wrote:
I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli Zhang.
This case proposes new interfaces to support copy reduction in the I/O path
especially for file sharing services.
Minor binding is requested.
This times out on Wednesday, 16 September, 2009.
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:
Copy Reduction Interfaces
1.2. Name of Document Author/Supplier:
Author: Mahesh Siddheshwar, Chunli Zhang
1.3 Date of This Document:
09 September, 2009
4. Technical Description
== 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 share data buffers
between the modules. It is intended to be used by network file
sharing services like NFS, CIFS or others.
Although the buffer sharing can be achieved through a few different
solutions, any such solution must work with File Event Monitors
(FEM monitors)[1] installed on the files. The solution must
allow the underlying filesystem to maintain any existing file
range locking in the filesystem.
The proposed solution provides extensions to the existing VOP
interface to request and return buffers from a filesystem. The
buffers are then used with existing VOP_READ/VOP_WRITE calls with
minimal changes.
== Proposed Changes ==
VOP Extensions for Zero-Copy Support
a. Extended struct uio, xuio_t
The following proposes an extensible uio structure that can be extended for
multiple purposes. For example, an immediate extension, xu_zc, is to be
used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to pass loaned
zero-copy buffers, as well as to be passed to the existing
VOP_READ/VOP_WRITE
calls for normal read/write operations. Another example of extension,
xu_aio, is intended to replace uioa_t for async I/O.
This new structure, xuio_t, contains the following:
- the existing uio structure (embedded) as the first member
- additional fields to support extensibility
- a union of all the defined extensions
The following uio_extflag is added to indicate that an uio structure is
indeed an xuio_t:
#define UIO_XUIO0x004 /* Structure is xuio_t */
The following uio_extflag will be removed after uioa_t has been converted
to xuio_t:
#define UIO_ASYNC 0x002 /* Structure is xuio_t */
The project team has commitment from the networking team to remove
the current use of uioa_t and use the proposed extensions (CR 6880095).
The definition of xuio_t is:
typedef struct xuio {
uio_t xu_uio; /* Embedded UIO structure */
/* Extended uio fields */
enum xuio_type xu_type; /* What kind of uio structure? */
union {
/* Async I/O Support */
struct {
uint32_t xu_a_state; /* state of async i/o */
uint32_t xu_a_state; /* state of async i/o */
ssize_t xu_a_mbytes; /* bytes that have been uioamove()ed */
uioa_page_t *xu_a_lcur; /* pointer into uioa_locked[] */
void **xu_a_lppp; /* pointer into lcur-uioa_ppp[] */
void *xu_a_hwst[4]; /* opaque hardware state */
uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov locked pages
*/
} xu_aio;
/* Zero Copy Support */
struct {
enum uio_rw xu_zc_rw; /* the use of the buffer */
void *xu_zc_priv; /* fs specific */
} xu_zc;
} xu_ext;
} xuio_t;
where xu_type is currently defined as:
typedef enum xuio_type {
UIOTYPE_ASYNCIO,
UIOTYPE_ZEROCOPY
} xuio_type_t;
New uio extensions can be added by defining a new xuio_type_t, and adding a
new member to the xu_ext union.
b. Requesting zero-copy buffers
#define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \
fop_reqzcbuf(vp, rwflag, uiozcp, cr, ct)
int fop_reqzcbuf(vnode_t *, enum uio_rw, xuio_t *, cred_t *,
caller_context_t *);
This function requests buffers associated with file vp in preparation for
a
subsequent zero
zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009]
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 information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: zpool recovery support 1.2. Name of Document Author/Supplier: Author: Timothy Haley 1.3 Date of This Document: 09 September, 2009 4. Technical Description OVERVIEW: Uncooperative or deceptive hardware, combined with power failures or sudden lack of access to devices, can result in zpools without redundancy being non-importable. ZFS' copy-on-write and Merkle tree properties will sometimes allow us to recover from these problems. Only ad-hoc means currently exist to take advantage of this recoverability. This proposal aims to rectify that short-coming. PROPOSED SOLUTION: This fast-track proposes two new command line flags each for the 'zpool clear' and 'zpool import' sub-commands. Both sub-commands will now accept a '-F' recovery mode flag. When specified, a determination is made if discarding the last few transactions performed in an unopenable or non-importable pool will return the pool to an usable state. If so, the transactions are irreversibly discarded, and the pool imported. If the pool is usable or already imported and this flag is specified, the flag is ignored and no transactions are discarded. Both sub-commands will now also accept a '-n' flag. This flag is only meaningful in conjunction with the '-F' flag. When specified, an attempt is made to see if discarding transactions will return the pool to a usable state, but no transactions are actually discarded. PROPOSED CHANGES to ZPOOL(1M) PAGE: --- zpool.1m.rogi Thu Aug 27 09:59:14 2009 +++ zpool.1mWed Sep 9 21:02:25 2009 @@ -18,7 +18,7 @@ zpool attach [-f] pool device new_device - zpool clear pool [device] + zpool clear [-n] [-F] pool [device] zpool create [-fn] [-o property=value] ... [-O file-system-property=value] @@ -44,11 +44,11 @@ zpool import [-o mntopts] [-p property=value] ... [-d dir | -c cachefile] - [-D] [-f] [-R root] -a + [-D] [-f] [-R root] [-n] [-F] -a zpool import [-o mntopts] [-o property=value] ... [-d dir | -c cachefile] - [-D] [-f] [-R root] pool |id [newpool] + [-D] [-f] [-R root] [-n] [-F] pool |id [newpool] zpool iostat [-v] [pool] ... [interval[count]] @@ -761,7 +761,7 @@ - zpool clear pool [device] ... + zpool clear [-n] [-F] pool [device] ... Clears device errors in a pool. If no arguments are specified, all device errors within the pool are @@ -769,7 +769,18 @@ errors associated with the specified device or devices are cleared. + -FInitiates recovery mode for a unopenable pool. + Attempts to discard the last few transactions in the + pool to return it to an openable state. Not all + damaged pools can be recovered by using this option. + If successful, the data from the discarded transactions + is irreversibly lost. + -nUsed in combination with the -F flag. Check if + discarding transactions would make the pool openable, + but do not actually discard any transactions. + + zpool create [-fn] [-o property=value] ... [-O file-system- property=value] ... [-m mountpoint] [-R root] pool vdev ... @@ -1016,7 +1027,7 @@ zpool import [-o mntopts] [ -o property=value] ... [-d dir | - -c cachefile] [-D] [-f] [-R root] -a + -c cachefile] [-D] [-f] [-n] [-F] [-R root] -a Imports all pools found in the search directories. Identical to the previous command, except that all pools @@ -1075,6 +1086,17 @@ appears to be potentially active. + -F Recovery mode for a non-importable pool. + Attempt to return the pool to an + importable state by discarding the last + few transactions. Not all damaged pools + can be recovered by using this option. + If successful, the data from the + discarded transactions is irreversibly + lost. This option is ignored if the pool + is importable or already imported. + + -a Searches for and imports all pools found. @@
zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009]
Tim Haley wrote: PROPOSED SOLUTION: This fast-track proposes two new command line flags each for the 'zpool clear' and 'zpool import' sub-commands. Both sub-commands will now accept a '-F' recovery mode flag. When specified, a determination is made if discarding the last few transactions performed in an unopenable or non-importable pool will return the pool to an usable state. If so, the transactions are irreversibly discarded, and the pool imported. If the pool is usable or already imported and this flag is specified, the flag is ignored and no transactions are discarded. Both sub-commands will now also accept a '-n' flag. This flag is only meaningful in conjunction with the '-F' flag. When specified, an attempt is made to see if discarding transactions will return the pool to a usable state, but no transactions are actually discarded. Here's a usability suggestion. Whenever clear or import fails, why not automatically do the equivalent of command -F -n (i.e. tell the user if recovery is possible)? If so, the user can invoke with -F if desired. There would be no need to create a -n option. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278)
zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009]
Scott Rotondo wrote: Tim Haley wrote: PROPOSED SOLUTION: This fast-track proposes two new command line flags each for the 'zpool clear' and 'zpool import' sub-commands. Both sub-commands will now accept a '-F' recovery mode flag. When specified, a determination is made if discarding the last few transactions performed in an unopenable or non-importable pool will return the pool to an usable state. If so, the transactions are irreversibly discarded, and the pool imported. If the pool is usable or already imported and this flag is specified, the flag is ignored and no transactions are discarded. Both sub-commands will now also accept a '-n' flag. This flag is only meaningful in conjunction with the '-F' flag. When specified, an attempt is made to see if discarding transactions will return the pool to a usable state, but no transactions are actually discarded. Here's a usability suggestion. Whenever clear or import fails, why not automatically do the equivalent of command -F -n (i.e. tell the user if recovery is possible)? If so, the user can invoke with -F if desired. There would be no need to create a -n option. That is exactly how it works in the prototype. The -n is still useful for reconfirming. -tim Scott
zpool recovery support [PSARC/2009/479 FastTrack timeout 09/16/2009]
Tim Haley wrote: Scott Rotondo wrote: Tim Haley wrote: PROPOSED SOLUTION: This fast-track proposes two new command line flags each for the 'zpool clear' and 'zpool import' sub-commands. Both sub-commands will now accept a '-F' recovery mode flag. When specified, a determination is made if discarding the last few transactions performed in an unopenable or non-importable pool will return the pool to an usable state. If so, the transactions are irreversibly discarded, and the pool imported. If the pool is usable or already imported and this flag is specified, the flag is ignored and no transactions are discarded. Both sub-commands will now also accept a '-n' flag. This flag is only meaningful in conjunction with the '-F' flag. When specified, an attempt is made to see if discarding transactions will return the pool to a usable state, but no transactions are actually discarded. Here's a usability suggestion. Whenever clear or import fails, why not automatically do the equivalent of command -F -n (i.e. tell the user if recovery is possible)? If so, the user can invoke with -F if desired. There would be no need to create a -n option. That is exactly how it works in the prototype. The -n is still useful for reconfirming. -tim OK, good. I'm less concerned about removing the -n than I am about making sure we automatically tell the user when he should try -F. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278)
Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009]
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 ought to be a full
case. I'd be a bit uncomfortable allowing this one to just time out
with a single +1, which is the normal rule for fast tracks.
Am I alone in this particular concern?
Are there any implications for unbundled 3rd party filesystems?
Not unless the 3rd party filesystem wants to support this optional
feature. This is covered in section (d) of the spec. The intermediate fop
routines handle it correctly.
Regards,
Mahesh
- Garrett
Rich.Brown at Sun.COM wrote:
I'm sponsoring this case on behalf of Mahesh Siddheshwar and Chunli
Zhang.
This case proposes new interfaces to support copy reduction in the
I/O path
especially for file sharing services.
Minor binding is requested.
This times out on Wednesday, 16 September, 2009.
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:
Copy Reduction Interfaces
1.2. Name of Document Author/Supplier:
Author: Mahesh Siddheshwar, Chunli Zhang
1.3 Date of This Document:
09 September, 2009
4. Technical Description
== 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 share data buffers
between the modules. It is intended to be used by network file
sharing services like NFS, CIFS or others.
Although the buffer sharing can be achieved through a few different
solutions, any such solution must work with File Event Monitors
(FEM monitors)[1] installed on the files. The solution must
allow the underlying filesystem to maintain any existing file range
locking in the filesystem.
The proposed solution provides extensions to the existing VOP
interface to request and return buffers from a filesystem. The
buffers are then used with existing VOP_READ/VOP_WRITE calls with
minimal changes.
== Proposed Changes ==
VOP Extensions for Zero-Copy Support
a. Extended struct uio, xuio_t
The following proposes an extensible uio structure that can be
extended for
multiple purposes. For example, an immediate extension, xu_zc, is
to be used by the proposed VOP_REQZCBUF/VOP_RETZCBUF interfaces to
pass loaned
zero-copy buffers, as well as to be passed to the existing
VOP_READ/VOP_WRITE
calls for normal read/write operations. Another example of extension,
xu_aio, is intended to replace uioa_t for async I/O.
This new structure, xuio_t, contains the following:
- the existing uio structure (embedded) as the first member
- additional fields to support extensibility
- a union of all the defined extensions
The following uio_extflag is added to indicate that an uio
structure is
indeed an xuio_t:
#defineUIO_XUIO0x004/* Structure is xuio_t */
The following uio_extflag will be removed after uioa_t has been
converted to xuio_t:
#defineUIO_ASYNC0x002/* Structure is xuio_t */
The project team has commitment from the networking team to remove
the current use of uioa_t and use the proposed extensions (CR
6880095).
The definition of xuio_t is:
typedef struct xuio {
uio_t xu_uio;/* Embedded UIO structure */
/* Extended uio fields */
enum xuio_type xu_type;/* What kind of uio structure? */
union {
/* Async I/O Support */
struct {
uint32_t xu_a_state;/* state of async i/o */
uint32_t xu_a_state;/* state of async i/o */
ssize_t xu_a_mbytes;/* bytes that have been
uioamove()ed */
uioa_page_t *xu_a_lcur;/* pointer into uioa_locked[] */
void **xu_a_lppp;/* pointer into lcur-uioa_ppp[] */
void *xu_a_hwst[4];/* opaque hardware state */
uioa_page_t xu_a_locked[UIOA_IOV_MAX]; /* Per iov
locked pages */
} xu_aio;
/* Zero Copy Support */
struct {
enum uio_rw xu_zc_rw;/* the use of the buffer */
void *xu_zc_priv;/* fs specific */
} xu_zc;
} xu_ext;
} xuio_t;
where xu_type is currently defined as:
typedef enum xuio_type {
UIOTYPE_ASYNCIO,
UIOTYPE_ZEROCOPY
} xuio_type_t;
New uio extensions can be added by defining a new xuio_type_t, and
adding a
new member to the xu_ext union.
b. Requesting zero-copy buffers
#define VOP_REQZCBUF(vp, rwflag, uiozcp, cr, ct) \
fop_reqzcbuf(vp, rwflag,
