From cth@sac.sfbay.sun.com Tue May 29 08:31:05 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TFV57U001016 for ; Tue, 29 May 2007 08:31:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4TFTkR3028139; Tue, 29 May 2007 08:29:47 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIT0030Z71NM200@brm-avmta-1.central.sun.com>; Tue, 29 May 2007 09:29:47 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIT00IFA71MOC50@brm-avmta-1.central.sun.com>; Tue, 29 May 2007 09:29:46 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l4TFTiEY025531; Tue, 29 May 2007 08:29:44 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l4TFV1tk000990; Tue, 29 May 2007 08:31:01 -0700 (PDT) Received: (from cth@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l4TFV1HI000986; Tue, 29 May 2007 08:31:01 -0700 (PDT) Date: Tue, 29 May 2007 08:31:01 -0700 (PDT) From: Christopher Horne Subject: Driver open-close exclusion guarantees [PSARC/2007/310 FastTrack timeout 06/06/2007] To: PSARC-ext@sun.com Cc: chris.gerhard@sun.com Message-id: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 18604 I am sponsoring this following fasttrack for myself, requesting patch binding and a timeout of 06/06/2007. Template Version: @(#)sac_nextcase 1.61 05/24/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Driver open-close exclusion guarantees 1.2. Name of Document Author/Supplier: Author: Chris Horne, Chris Gerhard 1.3 Date of This Document: 29 May, 2007 4. Technical Description: 4.1.1 Summary: This proposal clarifies the interaction between the kernel and a non-stream driver's open(9E) and close(9E) implementation. The proposal focuses on two aspects of this interaction: the execution exclusion guarantees between open(9E) and close(9E) calls, and the last-reference accounting associated with close(9E) calls. The proposal includes open(9E), close(9E), and cb_ops(9S) man page changes, as well as a man pages for ddi-open-returns-eintr(9P). The proposal requests patch binding. 4.1.1. Problems: UNIX has always used an open-close model where each device open results in an open(9E) call, and the last-reference close results in a single close(9E) call. While this basic model is simple and well understood, what this means for exclusion guarantees between open(9E) and close(9E) in a multi-threaded preemptive kernel environment like Solaris is not documented. UNIX last-reference accounting associated with a close(9E) call historically counted successfully completed open(9E) calls as 'open'. This works well in a single-threaded non-preemptive kernel environment, but it does not work well for Solaris. Solaris last-reference accounting has always treated in-progress open(9E) call as 'open', but this is not clearly documented. Without a clear definition of both the exclusion guarantees and last-reference accounting, it is difficult to write a reliable driver. 4.1.2. Proposal: This proposal defines, for non-streams drivers, execution exclusion guarantees between open(9E) and close(9E) calls, and last-reference accounting associated with close(9E) calls. 4.1.2.1 Exclusion: To provide open-close exclusion in a multi-threaded preemptive kernel environment like Solaris, an executing close(9E) call must act as a barrier to all subsequent open(9E) calls: the last-reference close(9E) call needs to return before the next open(9E) call is allowed to start. Today the kernel implements open-close exclusion for streams drivers, but not for non-streams drivers. Non-streams drivers either incorrectly assume exclusion or are complicated by needing to implement their own exclusion. When exclusion for non-streams drivers is implemented, in situations where an active close(9E) call is preventing a new open(9E) call due to exclusion, having the framework always treat the waiting-open as interruptible is unsafe - applications may not be coded to expect a new EINTR return from open. This proposal provides new interfaces that allow the framework to determine if a waiting-open is safely interruptible. Exclusion is provided at (dev_t, otyp) granularity, where dev_t and otyp refer to open(9E) arguments. The otyp values of interest are OTYP_BLK and OTYP_CHR. If this granularity is too fine-grained, the driver writer is left having to implement his own exclusion and accounting (often at ddi_get_instance(9F) granularity). Providing exclusion guarantees at instance granularity is outside the scope of this proposal. 4.1.2.2 Last-reference accounting: Last-reference accounting occurs at the same (dev_t, otyp) granularity as exclusion. Solaris last-reference accounting has always treated in-progress open(9E) calls as 'open', but this is not clearly documented. No change to last-reference accounting is proposed, however, an explanation of how accounting is implemented is necessary, especially for implementing 'special behaviors' where the driver open(9E) and close(9E) implementations interact. 4.1.2.3 Special Behaviors: Understanding exclusion guarantees and last-reference accounting typically simplify driver writing. However, for some behaviors additional guidance is still needed. Implementing these behaviors involves 'self-clone', where a driver changes the *devp value passed to open(9E). A driver that does a self-clone does not necessarily need to call ddi_create_minor_node(9F) for the new *devp value. o A driver that supports O_NDELAY (FNDELAY) and blocks in open(9E) or close(9E) for an event that takes a long time (or may never occur) must use separate minor nodes for O_NDELAY and non-O_NDELAY access for the applications to get real O_NDELAY behavior. Applications using the device must either match the minor node used with their O_NDELAY flag use, or the driver must self-clone to match O_NDELAY flag use. This guidance is related to both exclusion and last-reference accounting. For exclusion, this guidance prevents a new O_NDELAY open from waiting on completion of a non-O_NDELAY close(9E). For last-reference accounting, this guidance allows an O_NDELAY close(9E) to occur while there is a blocked non-O_NDELAY open(9E) call. This is already a de facto Solaris requirement: an example is the OUTLINE implementation used by serial communications drivers like zs(7D) . In this situation Solaris specific DDI considerations influence how a driver must implement a POSIX compliant O_NDELAY open(9E). An unmodified SVR4 driver's O_NDELAY open(9E) implementation may not be POSIX compliant under Solaris. NOTE: Some drivers (such as sd(7D)) use O_NDELAY to support administrative commands which need to open the device prior to full device initialization. These drivers fail their non-O_NDELAY open(9E) instead of blocking, so they do not need to use separate minor nodes. o A driver that blocks in open(9E) for an event signaled from close(9E) must self-clone. This guidance is related to last-reference accounting. If not followed, the close(9E) call will never occur since an in-progress open(9E) call counts as an 'open'. This is already a de facto Solaris requirement: an example is a queuing exclusive use device, like a printer. Originally, UNIX printer drivers slept in open(9E) if the device was already in use. This provided a driver-based queuing system. o A driver that blocks in close(9E) for an event that takes a long time (or may never occur) is preventing subsequent open(9E) operations. While blocking in close(9E) is not prohibited, the driver writer needs to understand the ramifications, possibly setting the D_OPEN_RETURNS_EINTR cb_ops(9S) flag or setting ddi-open-returns-eintr(9P) in driver.conf(4) if it is safe to return EINTR from open. This guidance is related to exclusions guarantees. This is already a de facto Solaris requirement for streams: an example is maximum drain times on close for streams. The ramifications of blocking indefinitely in close are not new for streams since streams currently has exclusion. Applications opening streams already expect EINTR, so the waiting-open can be interruptible. In the situations above, implementing multiple minor nodes or doing a 'self-clone' expands the operation beyond the typical (dev_t, otyp) granularity, so exclusion and last-reference accounting are no longer an impediment to implementing atypical behaviors. 4.1.2.4 Legacy non-DDI compliant interface issues: The Solaris open(9E) close(9E) exclusion guarantee is annulled when kernel software, other than specfs, uses the following private non-DDI interfaces: dev_open(), dev_close(), cb_ops(9S) cb_open, or cb_ops(9S) cb_close. If these private non-DDI interfaces are used, no new problems occur, but consumers should switch to use the Layered Driver Interfaces (LDI, PSARC 2001/769). LDI provides a DDI compliant way to perform these operations which does not annul exclusion guarantees. 4.2. Bug/RFE Number(s): 6343604 specfs race: multiple "last-close" of the same device 4127807 DDI: Is there a race between open(9e) and close(9e)? 4.5. Interfaces: ------------------------------------------------------------------------ Interface Level Comments ------------------------------------------------------------------------ Existing: open(9E) Committed Define exclusion and close(9E) " last-reference behavior. New: D_OPEN_RETURNS_EINTR " cb_ops(9S) cb_flag: Driver returns and applications expects EINTR from device open. ddi-open-returns-eintr(9P) " driver.conf(4) property: Driver returns and applications expects EINTR from device open. 6. Resources and Schedule: 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON 6.5. ARC review type: FastTrack A. Man page changes A.1 open(9E) man page changes: Driver Entry Points open(9E) NAME open - gain access to a device SYNOPSIS Block and Character #include #include #include #include #include #include #include int prefixopen(dev_t *devp, int flag, int otyp, cred_t *cred_p); STREAMS #include #include #include #include int prefixopen(queue_t *q, dev_t *devp, int oflag, int sflag, cred_t *cred_p); ---%<--- DESCRIPTION The driver's open() routine is called by the kernel during an open(2) or a mount(2) on the special file for the > device. A device may be opened simultaneously by multiple > processes and the open() driver routine is called for each > open. Note that a device is referenced once its associated > open(9E) routine is entered, and thus open(9E)'s which have > not yet completed will prevent close(9E) from being called. > | The routine should verify that the minor number component of *devp is valid, that the type of access requested by otyp and flag is appropriate for the device, and, if required, check permissions using the user credentials pointed to by cred_p. > The kernel provides open() close() exclusion guarantees to the > driver at (*devp, otyp) granularity. This delays new open() > calls to the driver while a last-reference close() call is > executing. If the driver has indicated that an EINTR return > is safe via the D_OPEN_RETURNS_EINTR cb_ops(9S) cb_fla or > ddi-open-returns-eintr(9P) then a delayed open() may be > interrupted by a signal, resulting in an EINTR return. > > Last-reference accounting and open() close() exclusion > typically simplify driver writing, however, in some cases they > may be an impediment for certain types of drivers. To overcome > any impediment the driver can change minor numbers in open(9E), > as described below, or implement multiple minor nodes for the > same device - both techniques give the driver control over > when close() calls will occur and whether additional open() > calls will be delayed while close() is executing. The open() routine is passed a pointer to a device number so that the driver can change the minor number. This allows drivers to dynamically create minor instances of the dev- ice. An example of this might be a pseudo-terminal driver that creates a new pseudo-terminal whenever it is opened. A driver that chooses the minor number dynamically, normally creates only one minor device node in attach(9E) with ddi_create_minor_node(9F) then changes the minor number com- ponent of *devp using makedevice(9F) and getmajor(9F). The driver needs to keep track of available minor numbers > internally. A driver that dynamically creates minor > numbers may want to avoid returning the original minor > number since returning the original minor will result in > postponed dynamic opens when original minor close() call > occurs. ---%<--- SEE ALSO > ddi-open-returns-eintr(9P), cb_ops(9S) ---%<--- A.2 close(9E) man page changes: Driver Entry Points close(9E) NAME close - relinquish access to a device SYNOPSIS Block and Character #include #include #include #include #include #include #include int prefixclose(dev_t dev, int flag, int otyp, cred_t *cred_p); ---%<--- DESCRIPTION For STREAMS drivers, the close() routine is called by the kernel through the cb_ops(9S) table entry for the device. (Modules use the fmodsw table.) A non-null value in the d_str field of the cb_ops entry points to a streamtab structure, which points to a qinit(9S) containing a pointer to the close() routine. Non-STREAMS close() routines are called directly from the cb_ops table. close() ends the connection between the user process and the device, and prepares the device (hardware and software) so that it is ready to be opened again. < A device may be opened simultaneously by multiple processes < and the open() driver routine is called for each open, but < the kernel will only call the close() routine when the last < process using the device issues a close(2) or umount(2) < system call or exits. (An exception is a close occurring < with the otyp argument set to OTYP_LYR, for which a close < (also having otyp = OTYP_LYR) occurs for each open.) > A device may be opened simultaneously by multiple processes > and the open() driver routine is called for each open. > For all otyp values other than OTYP_LYR the kernel calls > the close() routine when the last-reference occurs. For > OTYP_LYR each close operation will call the driver. > > Kernel accounting for last-reference occurs at (dev, otyp) > granularity. Note that a device is referenced once its > associated open(9E) routine is entered, and thus open(9E)'s > which have not yet completed will prevent close(9E) from > being called. The driver close(9E) call associated with the > last-reference going away is typically issued as as result > of a close(2), exit(2), munmap(2), or umount(2). However, a > failed open(9E) call can cause this last-reference close(9E) > call to be issued as a result of an open(2) or mount(2). > > The kernel provides open() close() exclusion guarantees > to the driver at the same (dev, otyp) granularity as > last-reference accounting. The kernel delays new calls to the > open() driver routine while the last-reference close() call is > executing - a driver that blocks in close() will not see new > calls to open() until it returns from close(). This > effectively delays invocation of other cb_ops(9S) driver entry > points that depend on an open(9E) established device reference > too. If the driver has indicated that an EINTR return > is safe via the D_OPEN_RETURNS_EINTR cb_ops(9S) cb_flag or > ddi-open-returns-eintr(9P) then a delayed open() may be > interrupted by a signal, resulting in an EINTR return from > open() prior to calling open(9E). > > Last-reference accounting and open() close() exclusion typically > simplify driver writing, however, in some cases they may be > an impediment for certain types of drivers. To overcome any > impediment the driver can change minor numbers in open(9E) > or implement multiple minor nodes for the same device - > both techniques give the driver control over when close() > calls will occur and whether additional open() calls will > be delayed while close() is executing. In general, a close() routine should always check the validity of the minor number component of the dev parameter. The routine should also check permissions as necessary, by using the user credential structure (if pertinent), and the appropriateness of the flag and otyp parameter values. ---%<--- SEE ALSO > ddi-open-returns-eintr(9P), cb_ops(9S) ---%<--- A.3 cb_ops(9S) man page change: If the driver properly handles 64-bit offsets, it should also set the D_64BIT flag in the cb_flag field. This speci- fies that the driver will use the uio_loffset field of the uio(9S) structure. + If the driver returns EINTR from open(9E), it should also set the + D_OPEN_RETURNS_EINTR flag in the cb_flag field. This lets the + framework know that it is safe for it to return EINTR when + waiting, to provide exclusion, for a last-reference close(9E) + call to complete before calling open(9E). + mt-streams(9F) describes other flags that can be set in the cb_flag field. cb_rev is the cb_ops structure revision number. This field must be set to CB_REV. A.4 ddi-open-returns-eintr.9p man page: Kernel Properties for Drivers ddi-open-returns-eintr(9P) NAME ddi-open-returns-eintr - property indicates that device open can safely return EINTR. DESCRIPTION When ddi-open-returns-eintr is set the kernel knows that an EINTR return from open(9E) is an expected result. This allows the kernel, in its implementation of open/close exclusion, to be interruptible and fail an open with EINTR when an active close(9E) operation, at (dev_t, spectype) granularity, is preventing a new open(9E). Set this property via driver.conf(4) if open(9E) implementation returns EINTR, especially when waiting for an active close(9E) operation. When property is set, kernel behavior is identical to when the D_OPEN_RETURNS_EINTR cb_ops(9S) cb_flag is set. SEE ALSO open(9E), close(9E), cb_ops(9S) Writing Device Drivers From Tim.Marsland@sun.com Fri Jun 1 00:36:00 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l517ZxMB018269 for ; Fri, 1 Jun 2007 00:36:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l517YPbO003737; Fri, 1 Jun 2007 08:34:37 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIY00I0551NVE00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 01 Jun 2007 00:34:35 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIY00KDB51MOF70@nwk-avmta-1.sfbay.Sun.COM>; Fri, 01 Jun 2007 00:34:34 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l517YYfP647748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 01 Jun 2007 00:34:34 -0700 (PDT) Received: (from tpm@localhost) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l517YYvm647747; Fri, 01 Jun 2007 00:34:34 -0700 (PDT) Date: Fri, 01 Jun 2007 00:34:34 -0700 From: Tim Marsland Subject: Re: Driver open-close exclusion guarantees [PSARC/2007/310 FastTrack timeout 06/06/2007] In-reply-to: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> To: Christopher Horne Cc: PSARC-ext@sun.com, chris.gerhard@sun.com Reply-to: Tim Marsland Message-id: <20070601073434.GH617100@eng.sun.com> Organization: Software; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 463 Why do we need *both* the cb_ops flag and the property? If you're having the property, what are the semantics if the property is only defined on a particular instance, rather than the driver? Also, if the property is changed/removed by the driver, when does the framework notice? Suggest that rather than invent answers to these questions, we should just use the cb_ops flag - it seems to be enough to express this particular, more structural, behaviour. tim From Chris.Horne@Sun.COM Fri Jun 1 09:03:09 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l51G39cl003745 for ; Fri, 1 Jun 2007 09:03:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l51G1jwR006491 for <@newsunmail1brm.central.sun.com:PSARC-ext@sun.com>; Fri, 1 Jun 2007 17:01:47 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIY00F17SIW6S00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 01 Jun 2007 10:01:44 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIY00C8USIWB050@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 01 Jun 2007 10:01:44 -0600 (MDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l51G1iX8023392 for ; Fri, 01 Jun 2007 16:01:44 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIY00601S94ZA00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 01 Jun 2007 10:01:44 -0600 (MDT) Received: from sun.com ([129.150.33.236]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIY008INSIVS210@mail-amer.sun.com>; Fri, 01 Jun 2007 10:01:43 -0600 (MDT) Date: Fri, 01 Jun 2007 10:01:43 -0600 From: Chris Horne Subject: Re: Driver open-close exclusion guarantees [PSARC/2007/310 FastTrack timeout 06/06/2007] In-reply-to: <20070601073434.GH617100@eng.sun.com> Sender: Chris.Horne@Sun.COM To: Tim Marsland Cc: Christopher Horne , psarc-ext@Sun.COM, Chris.Gerhard@Sun.COM Message-id: <466042E7.5070707@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> <20070601073434.GH617100@eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 Status: RO Content-Length: 1096 Tim Marsland wrote: > Why do we need *both* the cb_ops flag and the property? > > If you're having the property, what are the semantics if > the property is only defined on a particular instance, rather > than the driver? Also, if the property is changed/removed by > the driver, when does the framework notice? > > Suggest that rather than invent answers to these questions, we > should just use the cb_ops flag - it seems to be enough to express > this particular, more structural, behaviour. Would changing the commitment level on the property to "volatile", and not delivering property man page changes address your concern? The motivation for the property was to provide relief in the field if the new exclusion behavior causes problems. Getting a new driver with a patched cb_ops flag to the customer in a timely fashion, especially from a third party driver vendor, could prove difficult. Providing the property implementation as volatile still gives us a mechanism is help diagnose the problem and provide temporary relief until the cb_ops flag driver patch is available. -Chris From Tim.Marsland@sun.com Fri Jun 1 09:26:52 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l51GQqpj005811 for ; Fri, 1 Jun 2007 09:26:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l51GPSFn027467; Fri, 1 Jun 2007 09:25:29 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIY00G0PTMGN700@brm-avmta-1.central.sun.com>; Fri, 01 Jun 2007 10:25:28 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIY00CP8TMGAT60@brm-avmta-1.central.sun.com>; Fri, 01 Jun 2007 10:25:28 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l51GPR31722018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 01 Jun 2007 09:25:27 -0700 (PDT) Received: (from tpm@localhost) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l51GPRf1722017; Fri, 01 Jun 2007 09:25:27 -0700 (PDT) Date: Fri, 01 Jun 2007 09:25:27 -0700 From: Tim Marsland Subject: Re: Driver open-close exclusion guarantees [PSARC/2007/310 FastTrack timeout 06/06/2007] In-reply-to: <466042E7.5070707@sun.com> To: Chris Horne Cc: Tim Marsland , Christopher Horne , psarc-ext@sun.com, Chris.Gerhard@sun.com Reply-to: Tim Marsland Message-id: <20070601162527.GC711631@eng.sun.com> Organization: Software; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> <20070601073434.GH617100@eng.sun.com> <466042E7.5070707@sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1471 Well it certainly satisfies my architectural concern. However, I wonder if there's a useful precedent to set here w.r.t. the names of properties that are intended to be used this way e.g. prefix with a '.' or '__' -- a shorthand for the very low committment level. tim * Chris Horne [2007-06-01 09:02]: > Tim Marsland wrote: > > Why do we need *both* the cb_ops flag and the property? > > > > If you're having the property, what are the semantics if > > the property is only defined on a particular instance, rather > > than the driver? Also, if the property is changed/removed by > > the driver, when does the framework notice? > > > > Suggest that rather than invent answers to these questions, we > > should just use the cb_ops flag - it seems to be enough to express > > this particular, more structural, behaviour. > > Would changing the commitment level on the property to "volatile", and > not delivering property man page changes address your concern? > > The motivation for the property was to provide relief in the field if > the new exclusion behavior causes problems. Getting a new driver with > a patched cb_ops flag to the customer in a timely fashion, especially > from a third party driver vendor, could prove difficult. Providing the > property implementation as volatile still gives us a mechanism is help > diagnose the problem and provide temporary relief until the cb_ops flag > driver patch is available. > > -Chris From carlsonj@phorcys.east.sun.com Fri Jun 1 09:35:55 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l51GZtI3006621 for ; Fri, 1 Jun 2007 09:35:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l51GYBhG018250 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@Sun.COM>; Fri, 1 Jun 2007 17:34:33 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIY00E01U1JTS00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 01 Jun 2007 09:34:31 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIY00DCAU1I5FA0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 01 Jun 2007 09:34:30 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l51GYQlv022789; Fri, 01 Jun 2007 12:34:26 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l51GYQxd016770; Fri, 01 Jun 2007 12:34:26 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l51GYQ6c016767; Fri, 01 Jun 2007 12:34:26 -0400 (EDT) Date: Fri, 01 Jun 2007 12:34:26 -0400 From: James Carlson Subject: Re: Driver open-close exclusion guarantees [PSARC/2007/310 FastTrack timeout 06/06/2007] In-reply-to: <20070601162527.GC711631@eng.sun.com> To: Tim Marsland Cc: Chris Horne , Christopher Horne , psarc-ext@sun.com, Chris.Gerhard@sun.com Message-id: <18016.19090.647845.31684@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> <20070601073434.GH617100@eng.sun.com> <466042E7.5070707@sun.com> <20070601162527.GC711631@eng.sun.com> Status: RO Content-Length: 1020 Tim Marsland writes: > Well it certainly satisfies my architectural concern. > > However, I wonder if there's a useful precedent to set here > w.r.t. the names of properties that are intended to be used > this way e.g. prefix with a '.' or '__' -- a shorthand > for the very low committment level. If you later find that you need to raise the commitment level (perhaps because it turns out to be a more common problem than originally anticipated), then you end up having to do extra work to scrub away the commitment level from the variable name, and potentially issuing either patches or confusing documentation for it. Though I can see some value to it (easy to grep for "bad" usages over all drivers), I think I'd rather have that sort of meta information in the man page than in the code. -- James Carlson, Solaris Networking 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 From Tim.Marsland@sun.com Fri Jun 1 10:00:05 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l51H04FZ008866 for ; Fri, 1 Jun 2007 10:00:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l51GwPCM015339; Sat, 2 Jun 2007 00:58:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIY00J11V5H0V00@brm-avmta-1.central.sun.com>; Fri, 01 Jun 2007 10:58:29 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIY00CQXV5HAT90@brm-avmta-1.central.sun.com>; Fri, 01 Jun 2007 10:58:29 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l51GwTTG730644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 01 Jun 2007 09:58:29 -0700 (PDT) Received: (from tpm@localhost) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l51GwTf4730643; Fri, 01 Jun 2007 09:58:29 -0700 (PDT) Date: Fri, 01 Jun 2007 09:58:29 -0700 From: Tim Marsland Subject: Re: Driver open-close exclusion guarantees [PSARC/2007/310 FastTrack timeout 06/06/2007] In-reply-to: <18016.19090.647845.31684@gargle.gargle.HOWL> To: James Carlson Cc: Tim Marsland , Chris Horne , Christopher Horne , psarc-ext@sun.com, Chris.Gerhard@sun.com Reply-to: Tim Marsland Message-id: <20070601165828.GG711631@eng.sun.com> Organization: Software; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> <20070601073434.GH617100@eng.sun.com> <466042E7.5070707@sun.com> <20070601162527.GC711631@eng.sun.com> <18016.19090.647845.31684@gargle.gargle.HOWL> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1275 * James Carlson [2007-06-01 09:34]: > Tim Marsland writes: > > Well it certainly satisfies my architectural concern. > > > > However, I wonder if there's a useful precedent to set here > > w.r.t. the names of properties that are intended to be used > > this way e.g. prefix with a '.' or '__' -- a shorthand > > for the very low committment level. > > If you later find that you need to raise the commitment level (perhaps > because it turns out to be a more common problem than originally > anticipated), then you end up having to do extra work to scrub away > the commitment level from the variable name, and potentially issuing > either patches or confusing documentation for it. Aliases just aren't that hard. > Though I can see some value to it (easy to grep for "bad" usages over > all drivers), I think I'd rather have that sort of meta information in > the man page than in the code. But if it's something that doesn't have a manpage entry because its committment level and expectation-of-usage is so low, it seems a bit odd to create an entry simply so we can say "don't rely on this," on the offchance that we might want to raise the committment level later?? We should have a manpage entry when we raise the committment level. tim From carlsonj@phorcys.east.sun.com Fri Jun 1 10:11:30 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l51HBUPQ009957 for ; Fri, 1 Jun 2007 10:11:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l51H9kmB063991 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Fri, 1 Jun 2007 11:09:52 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIY0031NVOWTW00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 01 Jun 2007 10:10:08 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIY00HO6VOS6T60@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 01 Jun 2007 10:10:05 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l51HA0A6029448; Fri, 01 Jun 2007 13:10:00 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l51HA0lh016960; Fri, 01 Jun 2007 13:10:00 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l51HA0v0016957; Fri, 01 Jun 2007 13:10:00 -0400 (EDT) Date: Fri, 01 Jun 2007 13:10:00 -0400 From: James Carlson Subject: Re: Driver open-close exclusion guarantees [PSARC/2007/310 FastTrack timeout 06/06/2007] In-reply-to: <20070601165828.GG711631@eng.sun.com> To: Tim Marsland Cc: Chris Horne , Christopher Horne , psarc-ext@sun.com, Chris.Gerhard@sun.com Message-id: <18016.21224.324867.967023@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> <20070601073434.GH617100@eng.sun.com> <466042E7.5070707@sun.com> <20070601162527.GC711631@eng.sun.com> <18016.19090.647845.31684@gargle.gargle.HOWL> <20070601165828.GG711631@eng.sun.com> Status: RO Content-Length: 2456 Tim Marsland writes: > * James Carlson [2007-06-01 09:34]: > > If you later find that you need to raise the commitment level (perhaps > > because it turns out to be a more common problem than originally > > anticipated), then you end up having to do extra work to scrub away > > the commitment level from the variable name, and potentially issuing > > either patches or confusing documentation for it. > > Aliases just aren't that hard. They're not. But patches are. The broader issue is whether the commitment level ought to leak into the name and, if so, how much. We haven't done this in the past, so I think a change like this would be at best confusing at best. Does it mean that all non-"__"-prefixed tunables are now supposed to be public, but that we merely forgot to write man pages? Who rototills the code to "fix' this problem? I suppose that I just don't see a substantial benefit to carving out a namespace in driver.conf for private tunables. I think that at the point where you're hacking at those files, you're already far enough off in the weeds that carefully-controlled stability levels are of little consequence. In other words, we need better tools and techniques than just "vi /kernel/drv/foo.conf". > > Though I can see some value to it (easy to grep for "bad" usages over > > all drivers), I think I'd rather have that sort of meta information in > > the man page than in the code. > > But if it's something that doesn't have a manpage entry because its > committment level and expectation-of-usage is so low, it seems a bit > odd to create an entry simply so we can say "don't rely on this," on the > offchance that we might want to raise the committment level later?? I don't follow. I *think* you're objecting to the draft man page entry for the driver.conf tunable included with this project's case materials. If so, then reducing the commitment level means that we would *NOT* ship a decoy man page -- that text just remains as reference in the ARC case. > We should have a manpage entry when we raise the committment level. Indeed. I would object to shipping any man page for something that's deliberately kept private because we don't think it's necessary. -- James Carlson, Solaris Networking 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 From Chris.Horne@sun.com Fri Jun 1 19:34:02 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l522Y2gx027316 for ; Fri, 1 Jun 2007 19:34:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l522Wedb026188 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Fri, 1 Jun 2007 19:32:41 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIZ00D07LQGKB00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Jun 2007 20:32:40 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIZ00ERLLQEEVB0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Jun 2007 20:32:38 -0600 (MDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l522Wcul019150 for ; Sat, 02 Jun 2007 02:32:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIZ00E01LEEPZ00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Jun 2007 20:32:38 -0600 (MDT) Received: from sun.com ([129.150.33.236]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIZ008B3LQCS250@mail-amer.sun.com>; Fri, 01 Jun 2007 20:32:38 -0600 (MDT) Date: Fri, 01 Jun 2007 20:32:36 -0600 From: Chris Horne Subject: Re: Driver open-close exclusion guarantees [PSARC/2007/310 FastTrack timeout 06/06/2007] In-reply-to: <20070601162527.GC711631@eng.sun.com> Sender: Chris.Horne@sun.com To: Tim Marsland Cc: Christopher Horne , psarc-ext@sun.com, Chris.Gerhard@sun.com Message-id: <4660D6C4.50001@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> <20070601073434.GH617100@eng.sun.com> <466042E7.5070707@sun.com> <20070601162527.GC711631@eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 Status: RO Content-Length: 491 Tim Marsland wrote: > Well it certainly satisfies my architectural concern. I have updated the spec to make ddi-open-returns-eintr(9P) volatile. Diffs from previous spec are here: http://sac.eng/arc/PSARC/2007/310/materials/spec.diffs http://www.opensolaris.org/os/community/arc/caselog/2007/310/materials/spec.diffs New version of spec is here: http://sac.eng/arc/PSARC/2007/310/materials/spec.txt http://www.opensolaris.org/os/community/arc/caselog/2007/310/materials/spec.txt -Chris From Chris.Horne@Sun.COM Wed Jun 6 10:35:39 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l56HZdOP014552 for ; Wed, 6 Jun 2007 10:35:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l56HXre4036200 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 6 Jun 2007 11:33:53 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJ800701651FA00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 06 Jun 2007 10:34:14 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ800MBL651IGE0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 06 Jun 2007 10:34:13 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l56HYDw5012437 for ; Wed, 06 Jun 2007 17:34:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJ8007015VRWR00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 06 Jun 2007 11:34:13 -0600 (MDT) Received: from [172.20.25.50] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJ800MBD64G2BX8@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 06 Jun 2007 11:33:52 -0600 (MDT) Date: Wed, 06 Jun 2007 11:33:12 -0600 From: Chris Horne Subject: Re: Driver open-close exclusion guarantees [PSARC/2007/310 FastTrack timeout 06/06/2007] In-reply-to: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> Sender: Chris.Horne@Sun.COM To: psarc-ext@Sun.COM Cc: Chris.Gerhard@Sun.COM Message-id: <4666EFD8.2080008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705291531.l4TFV1HI000986@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 138 | 1.1. Project/Component Working Name: | Driver open-close exclusion guarantees This case was approved at today's psarc meeting. -Chris