From Calum.Mackay@sun.com Mon Apr 16 17:18:31 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 l3H0IU2c015075 for ; Mon, 16 Apr 2007 17:18:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3H0Hfmc009641 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Tue, 17 Apr 2007 08:17:47 +0800 (SGT) 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 <0JGM002098TLKK00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 16 Apr 2007 17:17:45 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGM002DD8TKIG00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 16 Apr 2007 17:17:45 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3H0HhpL005669 for ; Tue, 17 Apr 2007 00:17:43 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGM004018QCS800@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Apr 2007 01:17:43 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGM00HWQ8TI0VUZ@d1-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Apr 2007 01:17:43 +0100 (BST) Date: Tue, 17 Apr 2007 01:17:42 +0100 From: Calum Mackay Subject: 2007/218 caller_context_t in all VOPs Sender: Calum.Mackay@sun.com To: psarc-ext@sun.com Cc: Rich Brown Message-id: <46241226.1080406@sun.com> Organization: Sun Microsystems 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 User-Agent: Thunderbird 3.0a1 (X11/20070416) Status: RO Content-Length: 6984 I'm sponsoring the following fast-track for Rich Brown. The timer is set to next Weds, 25th April. The case seeks Minor binding. cheers, calum. CONTEXT This is one of several related fast-tracks describing VFS changes that were spun off of the CIFS Service (PSARC 2006/715) case. Although each of these changes are part of the bigger picture, they have been broken down into smaller pieces so each gets the attention it deserves. It must be noted that several of these fast-tracks will describe changes to the signatures of vnode operations (VOPs). In some cases, these fast-tracks will describe multiple changes to the same VOPs. The project team intends to put all of these changes into ON in a single putback. INTRODUCTION The following proposes to add an additional parameter, a pointer to a caller_context_t structure, to all vnode operations (VOPs) that do not already have it. This will allow caller information to be passed to FEM monitors on all VOPs. Currently, 6 of them already pass a caller_context_t pointer: VOP_READ, VOP_WRITE, VOP_SETATTR, VOP_RWLOCK, VOP_RWUNLOCK, and VOP_SPACE. This change modifies the remaining 38 VOPs as well as their corresponding "fop" routines and FEM-related routines. Minor binding is requested for this change. OPLOCK/DELEGATION COORDINATION The NFSv4 server has the ability to "delegate" control of a file to one (in the case of a write delegation) or more (in the case of a read delegation) NFSv4 clients. This feature significantly cuts down on over-the-wire traffic and can improve client performance. In order to manage delegations in the face of non-NFS access (e.g. local or CIFS access), the the NFS server installs FEM monitors to recall delegations when a conflicting operation occurs. The CIFS server has a similar feature where it can grant an "oplock" to one or more clients. As with NFS, the CIFS server will need to detect conflicting operations so that it can "break" (recall) the oplock before the conflicting operation is allowed to continue. The CIFS server will also install FEM monitors on operations so that it can detect conflicting operations and break any oplocks. Monitors can be placed on any vnode operation but often need information from the caller, such as the caller's identity, to work properly. For example, the NFSv4 server adds a set of delegation monitors on to the conflicting vnode operations (e.g., VOP_READ and VOP_WRITE) but action is needed only when a non-NFS caller attempts to access the delegated file. The monitor makes that determination by checking the caller's ID in the caller_context field passed in the vnode operation. Today, only a subset of the vnode operations pass the pointer to the caller_context structure as an argument. The CIFS server requires additional vnode operations, such as VOP_OPEN, to pass a pointer to caller_context. Experience from the NFSv4 Delegation-On-By-Default project shows that it is difficult to determine the minimal set of operations requiring monitors a priori. Given this experience, this project proposes to add caller_context to all vnode operations and all corresponding FEM-related operations that don't currently pass it. WHAT FILE SYSTEMS NEED TO CHANGE AND HOW? The only change to file systems is a signature change for the affected vnode operations. There is no behavioral changes needed. Rich Brown has already given a "heads-up" to Sun's contacts for unbundled file system developers (internal and external) that there will be signature changes. Those contacts will be given a full accounting of the changes once they've been completed. Note that Solaris Nevada now performs strong type-checking on vnode/FEM operations. This means that the compilers will inform the file system developers of the signature discrepancy in their code. All of the ON file systems will be updated with this change. Related cases: PSARC 2002/696 (added caller_context to VOP_READ, VOP_WRITE and friends) PSARC 2004/172 (added caller_context to VOP_SPACE, VOP_SETATTR, VOP_RWLOCK, VOP_RWUNLOCK and friends) PSARC/2007/124 Strong Type-Checking for VFS Operations Related Contracts PSARC 2001/599 (FS related interfaces for SAM-QFS) PSARC 2004/177 (FS related interfaces for Sun Cluster) EXPORTED INTERFACES: |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== |Contracted | | VOP_OPEN, fop_open, |Consolidation |This | Add new parameter: VOP_CLOSE, fop_close, |Private |Document | caller_context_t *ct VOP_IOCTL, fop_ioctl, | | | VOP_SETFL, fop_setfl, | | | VOP_GETATTR, | | | fop_getattr, | | | VOP_ACCESS, fop_access, | | | VOP_LOOKUP, fop_lookup, | | | VOP_CREATE, fop_create, | | | VOP_REMOVE, fop_remove, | | | VOP_LINK, fop_link, | | | VOP_RENAME, fop_rename, | | | VOP_MKDIR, fop_mkdir, | | | VOP_RMDIR, fop_rmdir, | | | VOP_READDIR, | | | fop_readdir, | | | VOP_SYMLINK, | | | fop_symlink, | | | VOP_READLINK, | | | fop_readlink, | | | VOP_FSYNC, fop_fsync, | | | VOP_INACTIVE, | | | fop_inactive, | | | VOP_FID, fop_fid, | | | VOP_SEEK, fop_seeks, | | | VOP_CMP, fop_cmp, | | | VOP_FRLOCK, fop_frlock, | | | VOP_REALVP, fop_realvp, | | | VOP_GETPAGE, | | | fop_getpage, | | | VOP_PUTPAGE, | | | fop_putpage, | | | VOP_MAP, fop_map, | | | VOP_ADDMAP, fop_addmap, | | | VOP_DELMAP, fop_delmap, | | | VOP_POLL, fop_poll, | | | VOP_DUMP, fop_dump, | | | VOP_PATHCONF, | | | fop_pathconf, | | | VOP_PAGEIO, fop_pageio, | | | VOP_DUMPCTL, | | | fop_dumpctl, | | | VOP_DISPOSE, | | | fop_dispose, | | | VOP_GETSECATTR, | | | fop_getsecattr, | | | VOP_SETSECATTR, | | | fop_setsecattr, | | | VOP_SHRLOCK, | | | fop_shrlock, | | | VOP_VNEVENT, | | | fop_vnevent | | | | | | vnext_open, | | | vnext_close, | | | vnext_ioctl, | | | vnext_setfl, | | | vnext_getattr, | | | vnext_access, | | | vnext_lookup, | | | vnext_create, | | | vnext_remove, | | | vnext_link, | | | vnext_rename, | | | vnext_mkdir, | | | vnext_rmdir, | | | vnext_readdir, | | | vnext_symlink, | | | vnext_readlink, | | | vnext_fsync, | | | vnext_inactive, | | | vnext_fid, | | | vnext_seek, | | | vnext_cmp, | | | vnext_frlock, | | | vnext_realvp, | | | vnext_getpage, | | | vnext_putpage, | | | vnext_map, | | | vnext_addmap, | | | vnext_delmap, | | | vnext_poll, | | | vnext_dump, | | | vnext_pathconf, | | | vnext_pageio, | | | vnext_dumpctl, | | | vnext_dispose, | | | vnext_setsecattr, | | | vnext_getsecattr, | | | vnext_shrlock, | | | vnext_vnevent | | | From Rich.Brown@sun.com Tue Apr 17 08:09:45 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 l3HF9ig0017084 for ; Tue, 17 Apr 2007 08:09:45 -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 l3HF8QR9029523 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Tue, 17 Apr 2007 16:09:01 +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 <0JGN0030BE2XKB00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Apr 2007 08:08:57 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGN000AVE2VHJ60@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Apr 2007 08:08:56 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3HF8trc011206 for ; Tue, 17 Apr 2007 15:08:55 +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 <0JGN00L01DYODP00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Apr 2007 09:08:55 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGN00JJ4E2T3TS4@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Apr 2007 09:08:54 -0600 (MDT) Date: Tue, 17 Apr 2007 10:08:52 -0500 From: Rich Brown Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <46241226.1080406@sun.com> Sender: Rich.Brown@sun.com To: psarc-ext@sun.com Cc: Calum Mackay , Rich.Brown@sun.com Message-id: <4624E304.3070901@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: <46241226.1080406@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 10761 This is an addendum to PSARC/2007/218 (caller_context_t in all VOPs). PSARC/2004/170 introduced a set of support routines to be used by file systems to invoke VOP_VNEVENT() with the appropriate arguments. Since VOP_VNEVENT() will be passing a caller_context parameter then the routines described in PSARC 2004/170 also need to pass caller_context. The new signatures are: int fs_vnevent_support(vnode_t *vp, vnevent_t vnevent, caller_context_t *ct) int fs_vnevent_nosupport(vnode_t *vp, vnevent_t vnevent, caller_context_t *ct) int vnevent_support(vnode_t *vp, caller_context_t *ct); void vnevent_rename_src(vnode_t *vp, caller_context_t *ct); void vnevent_rename_dest(vnode_t *vp, caller_context_t *ct); void vnevent_remove(vnode_t *vp, caller_context_t *ct); void vnevent_rmdir(vnode_t *vp, caller_context_t *ct); This does not change the behavior or the use of these routines, only the signatures so that caller_context can be passed to VOP_VNEVENT(). |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== |Contracted | | fs_vnevent_support() |Consolidation |This | Add new parameter: fs_vnevent_nosupport() |Private |Document | caller_context_t *ct vnevent_support() | | | vnevent_rename_src() | | | vnevent_rename_dest() | | | vnevent_remove() | | | vnevent_rmdir() | | | Calum Mackay wrote: > I'm sponsoring the following fast-track for Rich Brown. > > The timer is set to next Weds, 25th April. > > The case seeks Minor binding. > > cheers, > calum. > > > CONTEXT > > This is one of several related fast-tracks describing VFS changes > that were spun off of the CIFS Service (PSARC 2006/715) case. > Although each of these changes are part of the bigger picture, they > have been broken down into smaller pieces so each gets the attention > it deserves. > > It must be noted that several of these fast-tracks will describe > changes to the signatures of vnode operations (VOPs). In some cases, > these fast-tracks will describe multiple changes to the same VOPs. > The project team intends to put all of these changes into ON in a > single putback. > > INTRODUCTION > > The following proposes to add an additional parameter, a pointer to a > caller_context_t structure, to all vnode operations (VOPs) that do > not already have it. This will allow caller information to be passed > to FEM monitors on all VOPs. Currently, 6 of them already pass a > caller_context_t pointer: VOP_READ, VOP_WRITE, VOP_SETATTR, > VOP_RWLOCK, VOP_RWUNLOCK, and VOP_SPACE. This change modifies the > remaining 38 VOPs as well as their corresponding "fop" routines and > FEM-related routines. > > Minor binding is requested for this change. > > OPLOCK/DELEGATION COORDINATION > > The NFSv4 server has the ability to "delegate" control of a file to > one (in the case of a write delegation) or more (in the case of a > read delegation) NFSv4 clients. This feature significantly cuts down > on over-the-wire traffic and can improve client performance. In > order to manage delegations in the face of non-NFS access (e.g. > local or CIFS access), the the NFS server installs FEM monitors to > recall delegations when a conflicting operation occurs. > > The CIFS server has a similar feature where it can grant an "oplock" > to one or more clients. As with NFS, the CIFS server will need to > detect conflicting operations so that it can "break" (recall) the > oplock before the conflicting operation is allowed to continue. The > CIFS server will also install FEM monitors on operations so that it > can detect conflicting operations and break any oplocks. > > Monitors can be placed on any vnode operation but often need > information from the caller, such as the caller's identity, to work > properly. For example, the NFSv4 server adds a set of delegation > monitors on to the conflicting vnode operations (e.g., VOP_READ and > VOP_WRITE) but action is needed only when a non-NFS caller attempts > to access the delegated file. The monitor makes that determination > by checking the caller's ID in the caller_context field passed in the > vnode operation. > > Today, only a subset of the vnode operations pass the pointer to the > caller_context structure as an argument. The CIFS server requires > additional vnode operations, such as VOP_OPEN, to pass a pointer to > caller_context. Experience from the NFSv4 Delegation-On-By-Default > project shows that it is difficult to determine the minimal set of > operations requiring monitors a priori. Given this experience, this > project proposes to add caller_context to all vnode operations and > all corresponding FEM-related operations that don't currently pass > it. > > WHAT FILE SYSTEMS NEED TO CHANGE AND HOW? > > The only change to file systems is a signature change for the > affected vnode operations. There is no behavioral changes needed. > > Rich Brown has already given a "heads-up" to Sun's contacts for > unbundled file system developers (internal and external) that there > will be signature changes. Those contacts will be given a full > accounting of the changes once they've been completed. > > Note that Solaris Nevada now performs strong type-checking on > vnode/FEM operations. This means that the compilers will inform the > file system developers of the signature discrepancy in their code. > > All of the ON file systems will be updated with this change. > > Related cases: > PSARC 2002/696 (added caller_context to VOP_READ, VOP_WRITE and > friends) > PSARC 2004/172 (added caller_context to VOP_SPACE, VOP_SETATTR, > VOP_RWLOCK, VOP_RWUNLOCK and friends) > PSARC/2007/124 Strong Type-Checking for VFS Operations > > Related Contracts > PSARC 2001/599 (FS related interfaces for SAM-QFS) > PSARC 2004/177 (FS related interfaces for Sun Cluster) > > > EXPORTED INTERFACES: > > |Proposed |Specified | > |Stability |in what | > Interface Name |Classification |Document? | Comments > =============================================================================== > > |Contracted | | > VOP_OPEN, fop_open, |Consolidation |This | Add new parameter: > VOP_CLOSE, fop_close, |Private |Document | caller_context_t *ct > VOP_IOCTL, fop_ioctl, | | | > VOP_SETFL, fop_setfl, | | | > VOP_GETATTR, | | | > fop_getattr, | | | > VOP_ACCESS, fop_access, | | | > VOP_LOOKUP, fop_lookup, | | | > VOP_CREATE, fop_create, | | | > VOP_REMOVE, fop_remove, | | | > VOP_LINK, fop_link, | | | > VOP_RENAME, fop_rename, | | | > VOP_MKDIR, fop_mkdir, | | | > VOP_RMDIR, fop_rmdir, | | | > VOP_READDIR, | | | > fop_readdir, | | | > VOP_SYMLINK, | | | > fop_symlink, | | | > VOP_READLINK, | | | > fop_readlink, | | | > VOP_FSYNC, fop_fsync, | | | > VOP_INACTIVE, | | | > fop_inactive, | | | > VOP_FID, fop_fid, | | | > VOP_SEEK, fop_seeks, | | | > VOP_CMP, fop_cmp, | | | > VOP_FRLOCK, fop_frlock, | | | > VOP_REALVP, fop_realvp, | | | > VOP_GETPAGE, | | | > fop_getpage, | | | > VOP_PUTPAGE, | | | > fop_putpage, | | | > VOP_MAP, fop_map, | | | > VOP_ADDMAP, fop_addmap, | | | > VOP_DELMAP, fop_delmap, | | | > VOP_POLL, fop_poll, | | | > VOP_DUMP, fop_dump, | | | > VOP_PATHCONF, | | | > fop_pathconf, | | | > VOP_PAGEIO, fop_pageio, | | | > VOP_DUMPCTL, | | | > fop_dumpctl, | | | > VOP_DISPOSE, | | | > fop_dispose, | | | > VOP_GETSECATTR, | | | > fop_getsecattr, | | | > VOP_SETSECATTR, | | | > fop_setsecattr, | | | > VOP_SHRLOCK, | | | > fop_shrlock, | | | > VOP_VNEVENT, | | | > fop_vnevent | | | > | | | > vnext_open, | | | > vnext_close, | | | > vnext_ioctl, | | | > vnext_setfl, | | | > vnext_getattr, | | | > vnext_access, | | | > vnext_lookup, | | | > vnext_create, | | | > vnext_remove, | | | > vnext_link, | | | > vnext_rename, | | | > vnext_mkdir, | | | > vnext_rmdir, | | | > vnext_readdir, | | | > vnext_symlink, | | | > vnext_readlink, | | | > vnext_fsync, | | | > vnext_inactive, | | | > vnext_fid, | | | > vnext_seek, | | | > vnext_cmp, | | | > vnext_frlock, | | | > vnext_realvp, | | | > vnext_getpage, | | | > vnext_putpage, | | | > vnext_map, | | | > vnext_addmap, | | | > vnext_delmap, | | | > vnext_poll, | | | > vnext_dump, | | | > vnext_pathconf, | | | > vnext_pageio, | | | > vnext_dumpctl, | | | > vnext_dispose, | | | > vnext_setsecattr, | | | > vnext_getsecattr, | | | > vnext_shrlock, | | | > vnext_vnevent | | | > > From jgh@wizmail.org Tue Apr 17 12:43:17 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 l3HJhGmA000832 for ; Tue, 17 Apr 2007 12:43:17 -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 l3HJgSdd003277 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Tue, 17 Apr 2007 20:42:32 +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 <0JGN00I07QQV8800@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Apr 2007 12:42:31 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGN009VAQQVWW70@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 17 Apr 2007 12:42:31 -0700 (PDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.14] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3HJgPwH025159 for ; Tue, 17 Apr 2007 19:42:31 +0000 (GMT) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay21.sun.com with ESMTP id BT-MMP-483085 for psarc-ext@sun.com; Tue, 17 Apr 2007 19:42:25 +0000 (Z) Received: from mms24bas.mms.us.syntegra.com (relay24.mms.us.syntegra.com [192.12.251.70]) by mms24es.sun.com with ESMTP id BT-MMP-52375 for psarc-ext@sun.com; Tue, 17 Apr 2007 19:42:25 +0000 (Z) Received: from wizmail.org ([217.146.107.12] [217.146.107.12]) by relay24.sun.com with ESMTP id BT-MMP-6417696 for psarc-ext@sun.com; Tue, 17 Apr 2007 19:42:25 +0000 (Z) Received: from ebony.jgh.adsl.wizards.co.uk ([217.146.123.59]) (from_AS 16353) by wizmail.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.62) id 1HdtUx-0005fk-9j (return-path ); Tue, 17 Apr 2007 19:37:55 +0000 Date: Tue, 17 Apr 2007 20:42:23 +0100 From: Jeremy Harris Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <46241226.1080406@sun.com> To: psarc-ext@sun.com Message-id: <4625231F.90407@wizmail.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46241226.1080406@sun.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.10) Gecko/20070302 Fedora/1.5.0.10-1.fc6 pango-text Thunderbird/1.5.0.10 Mnenhy/0.7.5.0 Status: RO Content-Length: 1197 Calum Mackay wrote: > I'm sponsoring the following fast-track for Rich Brown. [...] > WHAT FILE SYSTEMS NEED TO CHANGE AND HOW? > > The only change to file systems is a signature change for the > affected vnode operations. There is no behavioral changes needed. > > Rich Brown has already given a "heads-up" to Sun's contacts for > unbundled file system developers (internal and external) that there > will be signature changes. Those contacts will be given a full > accounting of the changes once they've been completed. [...] > EXPORTED INTERFACES: > > |Proposed |Specified | > |Stability |in what | > Interface Name |Classification |Document? | Comments > =============================================================================== > > |Contracted | | > VOP_OPEN, fop_open, |Consolidation |This | Add new parameter: > VOP_CLOSE, fop_close, |Private |Document | caller_context_t *ct This seems to be an important interface, valuable for the introduction of new filesystems. Is there any intent (possibly not as part of this project) to upgrade the stability level? Jeremy Harris From Calum.Mackay@Sun.COM Tue Apr 17 15:06:23 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 l3HM6NQa006100 for ; Tue, 17 Apr 2007 15:06:23 -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 l3HM5dqZ061926 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 17 Apr 2007 16:05:39 -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 <0JGN00401XDFHN00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Tue, 17 Apr 2007 15:05:39 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGN000N4XDEHY50@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Tue, 17 Apr 2007 15:05:39 -0700 (PDT) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3HM5cZH020926 for ; Tue, 17 Apr 2007 22:05:38 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGN00L01X9T3200@d1-emea-10.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Tue, 17 Apr 2007 23:05:37 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGN0057ZXDDUPA9@d1-emea-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Tue, 17 Apr 2007 23:05:37 +0100 (BST) Date: Tue, 17 Apr 2007 23:05:34 +0100 From: Calum Mackay Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4625231F.90407@wizmail.org> Sender: Calum.Mackay@Sun.COM To: Jeremy Harris Cc: psarc-ext@Sun.COM Message-id: <462544AE.7020702@sun.com> Organization: Sun Microsystems 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: <46241226.1080406@sun.com> <4625231F.90407@wizmail.org> User-Agent: Thunderbird 3.0a1 (X11/20070416) Status: RO Content-Length: 1147 hi Jeremy, >> VOP_OPEN, fop_open, |Consolidation |This | Add new >> parameter: >> VOP_CLOSE, fop_close, |Private |Document | caller_context_t *ct > > This seems to be an important interface, valuable for the > introduction of new filesystems. Is there any intent > (possibly not as part of this project) to upgrade the > stability level? That's a great question :) We've certainly realised in the past the grief that not having a stable filesystem interface causes, and we continue to see (and to feel) that now. Various efforts have been made over the years, but it remains that the possible benefits may not overcome the considerable resources required, as things stand at the moment. However, this case, and others to follow soon, will help to sort out some of the things that make it difficult for us to upgrade the stability of the interfaces in general. In particular we have coming a VFS Feature Registration interface that will enable filesystems to register what special features they may support. So, things are getting better, slowly, and we hope to make more progress soon. best regards, calum. From glenn.skinner@sun.com Wed Apr 18 10:27:04 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 l3IHR4Jl012699 for ; Wed, 18 Apr 2007 10:27:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3IHQJha024048 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 18 Apr 2007 10:26:19 -0700 (PDT) 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 <0JGP00H07F3VIT00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 18 Apr 2007 10:26:19 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP009DKF3U1W80@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 18 Apr 2007 10:26:18 -0700 (PDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3IHQHPQ018330; Wed, 18 Apr 2007 10:26:17 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id l3IHO17o005688; Wed, 18 Apr 2007 10:24:01 -0700 (PDT) Date: Wed, 18 Apr 2007 10:24:01 -0700 (PDT) From: Glenn Skinner Subject: Re: 2007/218 caller_context_t in all VOPs To: psarc-ext@sun.com, Calum.Mackay@sun.com Cc: Rich.Brown@sun.com Reply-to: Glenn Skinner Message-id: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: YH/Yv1WJE/xQ8D9I6usjAw== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1174 Date: Tue, 17 Apr 2007 01:17:42 +0100 From: Calum Mackay Subject: 2007/218 caller_context_t in all VOPs ... WHAT FILE SYSTEMS NEED TO CHANGE AND HOW? The only change to file systems is a signature change for the affected vnode operations. There is no behavioral changes needed. Rich Brown has already given a "heads-up" to Sun's contacts for unbundled file system developers (internal and external) that there will be signature changes. Those contacts will be given a full accounting of the changes once they've been completed. Note that Solaris Nevada now performs strong type-checking on vnode/FEM operations. This means that the compilers will inform the file system developers of the signature discrepancy in their code. All of the ON file systems will be updated with this change. So you're saying that the integration of this case will constitute a flag day that will require all file systems to be updated and delivered simultaneously with the updated set of vnode ops? Is there any way to allow a phased changeover? -- Glenn From Rich.Brown@Sun.COM Wed Apr 18 11:45:13 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 l3IIjCuY017239 for ; Wed, 18 Apr 2007 11:45:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3IIiOqY020908; Thu, 19 Apr 2007 02:44:25 +0800 (SGT) 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 <0JGP00G05IPX1700@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Apr 2007 11:44:21 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP00F73IPW3A30@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Apr 2007 11:44:21 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3IIiKpW009050; Wed, 18 Apr 2007 18:44:20 +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 <0JGP00J01I99LH00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Wed, 18 Apr 2007 12:44:20 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGP003L9IPULT46@mail-amer.sun.com>; Wed, 18 Apr 2007 12:44:20 -0600 (MDT) Date: Wed, 18 Apr 2007 13:44:18 -0500 From: Rich Brown Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> Sender: Rich.Brown@Sun.COM To: Glenn Skinner Cc: psarc-ext@Sun.COM, Calum.Mackay@Sun.COM Message-id: <46266702.7000809@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1586 Glenn Skinner wrote: > Date: Tue, 17 Apr 2007 01:17:42 +0100 > From: Calum Mackay > Subject: 2007/218 caller_context_t in all VOPs > > ... > WHAT FILE SYSTEMS NEED TO CHANGE AND HOW? > > The only change to file systems is a signature change for the > affected vnode operations. There is no behavioral changes > needed. > > Rich Brown has already given a "heads-up" to Sun's contacts for > unbundled file system developers (internal and external) that > there will be signature changes. Those contacts will be given a > full accounting of the changes once they've been completed. > > Note that Solaris Nevada now performs strong type-checking on > vnode/FEM operations. This means that the compilers will inform > the file system developers of the signature discrepancy in their > code. > > All of the ON file systems will be updated with this change. > > So you're saying that the integration of this case will constitute a > flag day that will require all file systems to be updated and delivered > simultaneously with the updated set of vnode ops? > > Is there any way to allow a phased changeover? > > -- Glenn As far as the ON file systems go: The project team will update the ON file systems with these (and other related) changes. The ON file system changes will be integrated together with these changes in a single putback. The unbundled file systems will need to be updated separately by the respective FS development teams. Rich From Rich.Brown@sun.com Wed Apr 18 12:30:02 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 l3IJU11S019666 for ; Wed, 18 Apr 2007 12:30:02 -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 l3IJTEdN059103; Wed, 18 Apr 2007 13:29:16 -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 <0JGP00417KSQXJ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 12:29: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 <0JGP0007KKSNKTD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 12:29:11 -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 l3IJTBDl018022; Wed, 18 Apr 2007 19:29:11 +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 <0JGP00301KC51F00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Wed, 18 Apr 2007 13:29:11 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGP00D0GKSCNIQ9@mail-amer.sun.com>; Wed, 18 Apr 2007 13:29:04 -0600 (MDT) Date: Wed, 18 Apr 2007 14:28:59 -0500 From: Rich Brown Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <46266702.7000809@Sun.COM> Sender: Rich.Brown@sun.com To: Rich Brown , Glenn Skinner Cc: PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <4626717B.7000504@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 2082 Rich Brown wrote: > > Glenn Skinner wrote: >> Date: Tue, 17 Apr 2007 01:17:42 +0100 >> From: Calum Mackay >> Subject: 2007/218 caller_context_t in all VOPs >> >> ... >> WHAT FILE SYSTEMS NEED TO CHANGE AND HOW? >> >> The only change to file systems is a signature change for the >> affected vnode operations. There is no behavioral changes >> needed. >> >> Rich Brown has already given a "heads-up" to Sun's contacts for >> unbundled file system developers (internal and external) that >> there will be signature changes. Those contacts will be given a >> full accounting of the changes once they've been completed. >> >> Note that Solaris Nevada now performs strong type-checking on >> vnode/FEM operations. This means that the compilers will inform >> the file system developers of the signature discrepancy in their >> code. >> >> All of the ON file systems will be updated with this change. >> >> So you're saying that the integration of this case will constitute a >> flag day that will require all file systems to be updated and delivered >> simultaneously with the updated set of vnode ops? >> >> Is there any way to allow a phased changeover? >> >> -- Glenn > > As far as the ON file systems go: The project team will update the > ON file systems with these (and other related) changes. The ON file > system changes will be integrated together with these changes in a > single putback. > > The unbundled file systems will need to be updated separately by the > respective FS development teams. > > Rich Clarifying my clarification... :-) This is not an ON flag-day, but it does constitute a flag-day for unbundled file system developers. I've sent a message to Sun's internal contacts for 3rd party file systems warning of this change. I will continue to keep them informed. As far as the OpenSolaris community is concerned, I will find the appropriate discussion aliases to let them know of the upcoming changes. Rich From jek3@sun.com Wed Apr 18 14:13:45 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 l3ILDjde024769 for ; Wed, 18 Apr 2007 14:13:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3ILCwHY023148; Wed, 18 Apr 2007 15:12:58 -0600 (MDT) 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 <0JGP00B05PLM8L00@brm-avmta-1.central.sun.com>; Wed, 18 Apr 2007 15:12:58 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP009B9PLIHS20@brm-avmta-1.central.sun.com>; Wed, 18 Apr 2007 15:12:55 -0600 (MDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3ILCNBd317828; Wed, 18 Apr 2007 14:12:24 -0700 (PDT) Date: Wed, 18 Apr 2007 11:11:25 -1000 From: Joseph Kowalski Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <46266702.7000809@Sun.COM> To: Rich Brown Cc: Glenn Skinner , psarc-ext@sun.com, Calum.Mackay@sun.com Message-id: <4626897D.8060404@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 240 Rich Brown wrote: > The unbundled file systems will need to be updated separately by the > respective FS development teams. Do any of those deliver into Solaris (or even the extended developer wad centered arould Solaris Express)? - jek3 From Rich.Brown@sun.com Wed Apr 18 15:02:45 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 l3IM2iAx027133 for ; Wed, 18 Apr 2007 15:02:44 -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 l3IM1rO4004782; Wed, 18 Apr 2007 23:01:57 +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 <0JGP00209RV6MK00@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Apr 2007 15:01:54 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP00MMIRV6ZT70@nwk-avmta-2.sfbay.sun.com>; Wed, 18 Apr 2007 15:01:54 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3IM1r0F028848; Wed, 18 Apr 2007 22:01:53 +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 <0JGP00001RQK5500@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Wed, 18 Apr 2007 16:01:53 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGP003S6RV0LQJ6@mail-amer.sun.com>; Wed, 18 Apr 2007 16:01:50 -0600 (MDT) Date: Wed, 18 Apr 2007 17:01:48 -0500 From: Rich Brown Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4626897D.8060404@sun.com> Sender: Rich.Brown@sun.com To: Joseph Kowalski Cc: Glenn Skinner , PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <4626954C.1090304@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 465 Joseph Kowalski wrote: > Rich Brown wrote: >> The unbundled file systems will need to be updated separately by the >> respective FS development teams. > Do any of those deliver into Solaris (or even the extended developer wad > centered arould Solaris Express)? > > - jek3 > As far as I know we do not deliver unbundled file systems in Solaris Express. I'm following up with the unbundled FS folks to see if there is any exposure that I am unaware of. Rich From jek3@sun.com Wed Apr 18 15:51:51 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 l3IMpoLo028761 for ; Wed, 18 Apr 2007 15:51:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3IMosjc019033; Thu, 19 Apr 2007 06:50:59 +0800 (SGT) 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 <0JGP00M0DU4XI200@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 15:50:57 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGP005FBU4WSSA0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 18 Apr 2007 15:50:56 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3IMotsA335289; Wed, 18 Apr 2007 15:50:56 -0700 (PDT) Date: Wed, 18 Apr 2007 12:50:00 -1000 From: Joseph Kowalski Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4626954C.1090304@Sun.COM> To: Rich Brown Cc: Glenn Skinner , PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <4626A098.5030708@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 725 Rich Brown wrote: > > Joseph Kowalski wrote: >> Rich Brown wrote: >>> The unbundled file systems will need to be updated separately by the >>> respective FS development teams. >> Do any of those deliver into Solaris (or even the extended developer wad >> centered arould Solaris Express)? >> >> - jek3 >> > > As far as I know we do not deliver unbundled file systems in > Solaris Express. I'm following up with the unbundled FS folks > to see if there is any exposure that I am unaware of. > > Rich Thinking about this a bit more, is there any BINARY incompatibility here? Is the total effect that when you do a putback, the unbundled filesystems will have a nasty surprise next time they attempt to compile? - jek3 From Darren.Moffat@sun.com Thu Apr 19 03:29:19 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 l3JATIhn020613 for ; Thu, 19 Apr 2007 03:29:19 -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 l3JASQdg008528; Thu, 19 Apr 2007 11:28:32 +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 <0JGQ00H05QFJV100@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Apr 2007 03:28:31 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGQ00GDQQFI0YE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Apr 2007 03:28:30 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JASTUh023845; Thu, 19 Apr 2007 10:28:29 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGQ00001QD62300@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 19 Apr 2007 11:28:29 +0100 (BST) Received: from [129.150.120.43] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGQ005OZQFFIU10@d1-emea-09.sun.com>; Thu, 19 Apr 2007 11:28:29 +0100 (BST) Date: Thu, 19 Apr 2007 11:28:27 +0100 From: Darren J Moffat Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4626A098.5030708@sun.com> Sender: Darren.Moffat@sun.com To: Joseph Kowalski Cc: Rich Brown , Glenn Skinner , PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <4627444B.70304@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1051 Joseph Kowalski wrote: > Rich Brown wrote: >> >> Joseph Kowalski wrote: >>> Rich Brown wrote: >>>> The unbundled file systems will need to be updated separately by the >>>> respective FS development teams. >>> Do any of those deliver into Solaris (or even the extended developer wad >>> centered arould Solaris Express)? >>> >>> - jek3 >>> >> >> As far as I know we do not deliver unbundled file systems in >> Solaris Express. I'm following up with the unbundled FS folks >> to see if there is any exposure that I am unaware of. >> >> Rich > Thinking about this a bit more, is there any BINARY incompatibility here? Yes but thats only because the unbundled filesystems are using Consolidation Private (not even Contracted IIRC) interfaces. So hard luck. > Is the total effect that when you do a putback, the unbundled > filesystems will have a nasty surprise next time they attempt to compile? Thats what I understood, plus they old binaries won't work either. This is because we don't have a Committed VFS layer yet. -- Darren J Moffat From Rich.Brown@sun.com Thu Apr 19 06:26:14 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 l3JDQEjP025370 for ; Thu, 19 Apr 2007 06:26:14 -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 l3JDPSLG006141 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 19 Apr 2007 14:25:29 +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 <0JGQ0030BYMFTY00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 06:25:27 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGQ00DHXYMFRID0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 06:25:27 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JDPRZY020155 for ; Thu, 19 Apr 2007 13:25:27 +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 <0JGQ00001YLHCI00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 07:25:27 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGQ00JTFYMC3XV4@mail-amer.sun.com>; Thu, 19 Apr 2007 07:25:27 -0600 (MDT) Date: Thu, 19 Apr 2007 08:25:24 -0500 From: Rich Brown Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4626A098.5030708@sun.com> Sender: Rich.Brown@sun.com To: Joseph Kowalski Cc: PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <46276DC4.80208@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1618 Joseph Kowalski wrote: > Rich Brown wrote: >> >> Joseph Kowalski wrote: >>> Rich Brown wrote: >>>> The unbundled file systems will need to be updated separately by the >>>> respective FS development teams. >>> Do any of those deliver into Solaris (or even the extended developer wad >>> centered arould Solaris Express)? >>> >>> - jek3 >>> >> >> As far as I know we do not deliver unbundled file systems in >> Solaris Express. I'm following up with the unbundled FS folks >> to see if there is any exposure that I am unaware of. >> >> Rich > Thinking about this a bit more, is there any BINARY incompatibility here? > Yes, however, when this gets putback we will have bumped VFSDEF_VERSION (in sys/vfs.h) from 3 to 4. This means that unbundled file systems that haven't recompiled will not be allowed to have their modules load. I'll add a note to the "CONTEXT" (boiler plate) section of the subsequent related cases making the bump of VFSDEF_VERSION (and the implications) explicit. > Is the total effect that when you do a putback, the unbundled > filesystems will > have a nasty surprise next time they attempt to compile? > Now that the following has been integrated: PSARC/2007/124 Strong Type-Checking for VFS Operation Registration Mechanism When a developer attempts to compile an unbundled file system then s/he will get compilation errors due to the mismatch in the signatures for the vnode operations. Once the signatures are updated and the file system is recompiled, then the new VFSDEF_VERSION number will be picked up and the file system kernel module will be allowed to load. Rich From Rich.Brown@sun.com Thu Apr 19 06:26:47 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 l3JDQlX6025395 for ; Thu, 19 Apr 2007 06:26:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3JDQ1sd011433; Thu, 19 Apr 2007 06:26:03 -0700 (PDT) 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 <0JGQ0030PYNEUU00@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 06:26:02 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGQ00DPRYNDRDC0@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 06:26:01 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JDQ1cg020372; Thu, 19 Apr 2007 13:26:01 +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 <0JGQ00001YLHCI00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Thu, 19 Apr 2007 07:26:01 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGQ00JV7YNB3TT5@mail-amer.sun.com>; Thu, 19 Apr 2007 07:26:01 -0600 (MDT) Date: Thu, 19 Apr 2007 08:25:59 -0500 From: Rich Brown Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4627444B.70304@Sun.COM> Sender: Rich.Brown@sun.com To: Darren J Moffat Cc: Joseph Kowalski , Glenn Skinner , PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <46276DE7.9090008@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <4627444B.70304@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1154 Darren J Moffat wrote: > Joseph Kowalski wrote: >> Rich Brown wrote: >>> >>> Joseph Kowalski wrote: >>>> Rich Brown wrote: >>>>> The unbundled file systems will need to be updated separately by the >>>>> respective FS development teams. >>>> Do any of those deliver into Solaris (or even the extended developer >>>> wad >>>> centered arould Solaris Express)? >>>> >>>> - jek3 >>>> >>> >>> As far as I know we do not deliver unbundled file systems in >>> Solaris Express. I'm following up with the unbundled FS folks >>> to see if there is any exposure that I am unaware of. >>> >>> Rich >> Thinking about this a bit more, is there any BINARY incompatibility here? > > Yes but thats only because the unbundled filesystems are using > Consolidation Private (not even Contracted IIRC) interfaces. So hard luck. > >> Is the total effect that when you do a putback, the unbundled >> filesystems will have a nasty surprise next time they attempt to compile? > > Thats what I understood, plus they old binaries won't work either. > > This is because we don't have a Committed VFS layer yet. > All true. See my previous response to jek3. Rich From John.Plocher@sun.com Thu Apr 19 10:22:10 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 l3JHMAGs005395 for ; Thu, 19 Apr 2007 10:22:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3JHLOTE033925 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 19 Apr 2007 11:21:25 -0600 (MDT) 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 <0JGR00E079JP7C00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 10:21:25 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00DCA9JPFS10@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 10:21:25 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JHLOXe006843 for ; Thu, 19 Apr 2007 10:21:24 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGR00C019F2I500@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 10:21:24 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGR00M339JOD70B@d1-sfbay-10.sun.com>; Thu, 19 Apr 2007 10:21:24 -0700 (PDT) Date: Thu, 19 Apr 2007 10:21:21 -0700 From: John Plocher Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <46276DC4.80208@Sun.COM> Sender: John.Plocher@sun.com To: Rich Brown Cc: Joseph Kowalski , PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <4627A511.4050409@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 903 Rich Brown wrote: >> Thinking about this a bit more, is there any BINARY incompatibility here? >> > > Yes, however, when this gets putback we will have bumped VFSDEF_VERSION > (in sys/vfs.h) from 3 to 4. This means that unbundled file systems that > haven't recompiled will not be allowed to have their modules load. [looking for a 2 or 3 sentence answer here, not a long explanation] Have you looked into providing any sort of runtime transition support for older modules? I.e., if a rev=3 module tries to load, set them up with an "old signature vector with NOOP in new position", else use new structure (or whatever...) Depending on what filesystems exist out in the wild, the interfaces may be defacto "more committed" than the strict consolidation-private indicates. A transition mechanism (even if only for a limited time) could be an extremely useful tool to reduce the pain... -John From bart.smaalders@sun.com Thu Apr 19 10:57:04 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 l3JHv43f006665 for ; Thu, 19 Apr 2007 10:57:04 -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 l3JHuItg006276; Thu, 19 Apr 2007 10:56:19 -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 <0JGR00J0FB5URC00@brm-avmta-1.central.sun.com>; Thu, 19 Apr 2007 11:56:18 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00M57B5T6WC0@brm-avmta-1.central.sun.com>; Thu, 19 Apr 2007 11:56:18 -0600 (MDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l3JHuGCp029644; Thu, 19 Apr 2007 10:56:16 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l3JHuExN011859; Thu, 19 Apr 2007 10:56:15 -0700 (PDT) Date: Thu, 19 Apr 2007 10:55:04 -0700 From: Bart Smaalders Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4627A511.4050409@Sun.Com> To: John Plocher Cc: Rich Brown , PSARC-EXT@sun.com, Calum.Mackay@sun.com, Joseph Kowalski Message-id: <4627ACF8.2060709@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627A511.4050409@Sun.Com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1632 John Plocher wrote: > Rich Brown wrote: >>> Thinking about this a bit more, is there any BINARY incompatibility >>> here? >>> >> >> Yes, however, when this gets putback we will have bumped VFSDEF_VERSION >> (in sys/vfs.h) from 3 to 4. This means that unbundled file systems that >> haven't recompiled will not be allowed to have their modules load. > > [looking for a 2 or 3 sentence answer here, not a long explanation] > > Have you looked into providing any sort of runtime transition support > for older modules? I.e., if a rev=3 module tries to load, set them > up with an "old signature vector with NOOP in new position", else > use new structure (or whatever...) > > Depending on what filesystems exist out in the wild, the interfaces > may be defacto "more committed" than the strict consolidation-private > indicates. A transition mechanism (even if only for a limited time) > could be an extremely useful tool to reduce the pain... > Remember: > > Minor binding is requested for this change. What third party filesystems are available for OpenSolaris? Escalating the commitment level of interfaces because someone external has written some code to them is rewarding bad behavior. For OSS, they can recompile. Commercial non-oss vendors who do this can suck it up and release a patch or new version; personally, I don't think there are any supporting OpenSolaris with their products today. We're not breaking someone in a patch; we're breaking them when we ship the next minor version of Solaris. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sommerfeld@sun.com Thu Apr 19 11:12:06 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 l3JIC57I007291 for ; Thu, 19 Apr 2007 11:12:06 -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 l3JIAuFI012713; Fri, 20 Apr 2007 02:11:13 +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 <0JGR00L0BBUO4O00@brm-avmta-1.central.sun.com>; Thu, 19 Apr 2007 12:11:12 -0600 (MDT) Received: from localhost.east.sun.com ([129.148.19.3]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00MZBBUN6HD0@brm-avmta-1.central.sun.com>; Thu, 19 Apr 2007 12:11:11 -0600 (MDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3JIBAFl002992; Thu, 19 Apr 2007 14:11:10 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l3JIB91U002991; Thu, 19 Apr 2007 14:11:09 -0400 (EDT) Date: Thu, 19 Apr 2007 14:11:08 -0400 From: Bill Sommerfeld Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4627ACF8.2060709@Sun.COM> To: Bart Smaalders Cc: John Plocher , Rich Brown , Calum.Mackay@sun.com, Joseph Kowalski , PSARC-EXT@sun.com Message-id: <1177006268.1591.39.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627A511.4050409@Sun.Com> <4627ACF8.2060709@Sun.COM> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 685 On Thu, 2007-04-19 at 10:55 -0700, Bart Smaalders wrote: > Escalating the commitment level of interfaces because > someone external has written some code to them is rewarding > bad behavior. True in general, but in this specific case, the ARC has recognized the need for third-party filesystems to run on solaris and has felt that work should be done so that the VFS/vnode interfaces can be raised in commitment level. > We're not breaking someone in a patch; we're breaking > them when we ship the next minor version of Solaris. but in this case, the interfaces in question are formally Consolidation Private. Moving to Uncommitted would be a big step forward. - Bill From prakash.sangappa@sun.com Thu Apr 19 11:44:42 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 l3JIigrg008308 for ; Thu, 19 Apr 2007 11:44:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3JIhstv011350; Thu, 19 Apr 2007 11:43:55 -0700 (PDT) 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 <0JGR00H1BDD7KY00@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 11:43:55 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00DQEDD6FR70@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 11:43:54 -0700 (PDT) Received: from [129.146.228.98] (justforkicks.SFBay.Sun.COM [129.146.228.98]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3JIhrHl484684; Thu, 19 Apr 2007 11:43:54 -0700 (PDT) Date: Thu, 19 Apr 2007 11:43:31 -0700 From: Prakash Sangappa Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <46276DC4.80208@Sun.COM> To: Rich Brown Cc: Joseph Kowalski , PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <4627B853.6090902@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> User-Agent: Mail/News 1.5.0.4 (X11/20060701) Status: RO Content-Length: 1025 Rich Brown wrote: > > > PSARC/2007/124 Strong Type-Checking for VFS Operation Registration > Mechanism > > When a developer attempts to compile an unbundled file system > then s/he will get compilation errors due to the mismatch in the > signatures for the vnode operations. > > Once the signatures are updated and the file system is recompiled, > then the new VFSDEF_VERSION number will be picked up and the file > system kernel module will be allowed to load. > What about versioning vnode operations? We can have monitor type modules which can define vnode operations but do not necessarily have to define a vfsdef_t. These modules can intercept vnode operations via FEM. So, bumping up just the VFSDEF_VERSION will not be enough to recognize a monitor type module which could be using the older VOP interfaces. We will need a mechanism to version the vnode ops separately from VFS operations since there is no version number member defined in the 'fs_operation_def_t' VOP names template. -Prakash. > Rich From Rich.Brown@Sun.COM Thu Apr 19 11:51:06 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 l3JIp6Wa008464 for ; Thu, 19 Apr 2007 11:51:06 -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 l3JIoJLP009621 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 19 Apr 2007 19:50:19 +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 <0JGR00F0XDNUUI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 11:50:18 -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 <0JGR00DJJDNT3H80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 11:50:17 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JIoHnX008095 for ; Thu, 19 Apr 2007 18:50:17 +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 <0JGR00B01DNMWH00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 12:50:17 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGR00JDTDNQ3YQ3@mail-amer.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 12:50:17 -0600 (MDT) Date: Thu, 19 Apr 2007 13:50:14 -0500 From: Rich Brown Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4627A511.4050409@Sun.Com> Sender: Rich.Brown@Sun.COM To: John Plocher Cc: PSARC-EXT@Sun.COM, Calum.Mackay@Sun.COM, Rich.Brown@Sun.COM Message-id: <4627B9E6.9030605@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627A511.4050409@Sun.Com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1151 John Plocher wrote: > Rich Brown wrote: >>> Thinking about this a bit more, is there any BINARY incompatibility >>> here? >>> >> >> Yes, however, when this gets putback we will have bumped VFSDEF_VERSION >> (in sys/vfs.h) from 3 to 4. This means that unbundled file systems that >> haven't recompiled will not be allowed to have their modules load. > > [looking for a 2 or 3 sentence answer here, not a long explanation] > > Have you looked into providing any sort of runtime transition support > for older modules? I.e., if a rev=3 module tries to load, set them > up with an "old signature vector with NOOP in new position", else > use new structure (or whatever...) > > Depending on what filesystems exist out in the wild, the interfaces > may be defacto "more committed" than the strict consolidation-private > indicates. A transition mechanism (even if only for a limited time) > could be an extremely useful tool to reduce the pain... > > -John > > There are ideas for evolving the VFS interface, particularly in the face of Solaris updates, but those are still in the brainstorming stage and that work has not been funded. Rich From Frank.Vanderlinden@sun.com Thu Apr 19 13:05:42 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 l3JK5feW011358 for ; Thu, 19 Apr 2007 13:05:41 -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 l3JK4lv0008186; Thu, 19 Apr 2007 21:04:53 +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 <0JGR00L1NH429R00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Apr 2007 13:04:50 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00II6H401A60@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Apr 2007 13:04:49 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JK4mLB015770; Thu, 19 Apr 2007 20:04:48 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGR00F01H0P2Z00@d1-emea-09.sun.com> (original mail from Frank.Vanderlinden@Sun.COM); Thu, 19 Apr 2007 21:04:48 +0100 (BST) Received: from [192.168.0.201] ([24.132.232.60]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGR00H9JH3V17R3@d1-emea-09.sun.com>; Thu, 19 Apr 2007 21:04:47 +0100 (BST) Date: Thu, 19 Apr 2007 22:04:41 +0200 From: Frank Van Der Linden Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4627ACF8.2060709@Sun.COM> Sender: Frank.Vanderlinden@sun.com To: Bart Smaalders Cc: John Plocher , Rich Brown , Calum.Mackay@sun.com, Joseph Kowalski , PSARC-EXT@sun.com Message-id: <4627CB59.9020805@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627A511.4050409@Sun.Com> <4627ACF8.2060709@Sun.COM> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 268 Bart Smaalders wrote: > > What third party filesystems are available for OpenSolaris? OpenAFS has been mentioned.. also, hgfs (hostfs) for VMware. Not that I think it's a huge issue if they break with the next minor release, I just wanted to mention it :) - Frank From Rich.Brown@Sun.COM Thu Apr 19 13:20:14 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 l3JKKE0W011742 for ; Thu, 19 Apr 2007 13:20:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3JKJTW1023500; Thu, 19 Apr 2007 14:19:29 -0600 (MDT) 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 <0JGR00L07HSFU400@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 13:19:27 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00DCZHSFFRE0@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 13:19:27 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JKJQRW026423; Thu, 19 Apr 2007 20:19:26 +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 <0JGR00F01HK18H00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Thu, 19 Apr 2007 14:19:26 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGR00JJUHSD41J6@mail-amer.sun.com>; Thu, 19 Apr 2007 14:19:26 -0600 (MDT) Date: Thu, 19 Apr 2007 15:19:25 -0500 From: Rich Brown Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <1177006268.1591.39.camel@localhost> Sender: Rich.Brown@Sun.COM To: Bill Sommerfeld Cc: Calum.Mackay@Sun.COM, PSARC-EXT@Sun.COM Message-id: <4627CECC.20802@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627A511.4050409@Sun.Com> <4627ACF8.2060709@Sun.COM> <1177006268.1591.39.camel@localhost> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1048 Bill Sommerfeld wrote: > On Thu, 2007-04-19 at 10:55 -0700, Bart Smaalders wrote: > >> Escalating the commitment level of interfaces because >> someone external has written some code to them is rewarding >> bad behavior. > > True in general, but in this specific case, the ARC has recognized the > need for third-party filesystems to run on solaris and has felt that > work should be done so that the VFS/vnode interfaces can be raised in > commitment level. > >> We're not breaking someone in a patch; we're breaking >> them when we ship the next minor version of Solaris. > > but in this case, the interfaces in question are formally Consolidation > Private. Moving to Uncommitted would be a big step forward. > > - Bill > I think that it's worth it for a team to take on the work needed to raise the commitment level of the VFS/vnode interfaces. That work is out of the scope of this project. Having the ARC provide strong advice to the appropriate steering committee or PAC would probably help that work get funded. Rich From John.Plocher@sun.com Thu Apr 19 13:47:52 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 l3JKlqZa012402 for ; Thu, 19 Apr 2007 13:47:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3JKl5ZQ028567; Thu, 19 Apr 2007 13:47:07 -0700 (PDT) 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 <0JGR00059J2IW900@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Apr 2007 13:47:06 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00I8UJ2G1AE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Apr 2007 13:47:04 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JKl4v6002364; Thu, 19 Apr 2007 13:47:04 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGR00D01IY83000@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Thu, 19 Apr 2007 13:47:04 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGR001L3J26AV3A@d1-sfbay-09.sun.com>; Thu, 19 Apr 2007 13:46:54 -0700 (PDT) Date: Thu, 19 Apr 2007 13:46:50 -0700 From: John Plocher Subject: Re: 2007/218 caller_context_t in all VOPs (+ thoughts about the Interface Taxonomy) In-reply-to: <4627CB59.9020805@Sun.COM> Sender: John.Plocher@sun.com To: Frank Van Der Linden Cc: Bart Smaalders , Rich Brown , Calum.Mackay@sun.com, Joseph Kowalski , PSARC-EXT@sun.com Message-id: <4627D53A.80405@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627A511.4050409@Sun.Com> <4627ACF8.2060709@Sun.COM> <4627CB59.9020805@Sun.COM> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 2047 Frank Van Der Linden wrote: > Bart Smaalders wrote: >> >> What third party filesystems are available for OpenSolaris? > OpenAFS has been mentioned.. also, hgfs (hostfs) for VMware. > > Not that I think it's a huge issue if they break with the next minor > release, I just wanted to mention it :) The implication I'm concerned about is that those 3rd party apps that "just work" today for OpenSolaris will break with this putback and vendors won't release updated apps in a timely manner, so they will no longer work on OpenSolaris... I understand Bart's POV that we need to be able to change things in this arena; we also be aware of - and accept - the consequences of doing so. -John PS - a word about the interface taxonomy.... The various designations (Committed, Uncommitted, Consolidation Private, Project Private...) do NOT map to words like SECRET or NOT ALLOWED TO USE. Instead, they simply set expectations. You can USE any interface in Solaris that you can find. You simply need to be aware of the level of commitment that the interface's producer has for it - and be willing to react to changes as required. As OpenSolaris Community members, you can find all sorts of things to play with. This is good - go play with them. But, before you go beyond playing and move on to developing new projects/products, be aware of the stability of the interfaces you are depending upon - or you may end up with an unmaintainable house of cards. There is nothing wrong with OpenAFS using the VFS vnode interface. There is everything wrong with the AFS project if they expected it all to remain stable over time. As long as the OpenAFS team is aware of the risk that the VFS interfaces could change, and are willing to recode/recompile when they do change, everyone should be happy. Of course, if there is a mismatch in expectations between the producer and consumer (or worse, between the producer and the *users* of the consumer's product), then bad things happen. Preventing those "bad things" is the reason we do this stuff. From John.Plocher@sun.com Thu Apr 19 13:47:54 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 l3JKls0a012406 for ; Thu, 19 Apr 2007 13:47:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3JKl4cC028559 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 19 Apr 2007 13:47:09 -0700 (PDT) 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 <0JGR00N0TJ2L0U00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 13:47:09 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00M7MJ2KMK10@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 13:47:08 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JKl8qv014348 for ; Thu, 19 Apr 2007 13:47:08 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGR00D01IY83000@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 13:47:08 -0700 (PDT) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGR001L5J2BAU8X@d1-sfbay-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 13:46:59 -0700 (PDT) Date: Thu, 19 Apr 2007 13:46:55 -0700 From: John Plocher Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4627B9E6.9030605@Sun.COM> Sender: John.Plocher@sun.com To: Rich Brown Cc: PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <4627D53F.1060800@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627A511.4050409@Sun.Com> <4627B9E6.9030605@Sun.COM> User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) Status: RO Content-Length: 530 Rich Brown wrote: > There are ideas for evolving the VFS interface, particularly in the face > of Solaris updates, but those are still in the brainstorming stage and > that work has not been funded. For various reasons (not all technical), Sun has not been able to bring a project to create and expose a public VFS interface to fruition. This history implies that such a project isn't trivial. Nevertheless, it is an obviously needed and worthwhile thing to do. Any takers to start and lead a new Project to do this? -John From Rich.Brown@sun.com Thu Apr 19 13:51:57 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 l3JKpupe012703 for ; Thu, 19 Apr 2007 13:51:56 -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 l3JKp1Lk024656 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 19 Apr 2007 21:51:11 +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 <0JGR0000HJ9A1900@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 13:51:10 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00MMHJ9AML10@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 13:51:10 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JKp9tI028145 for ; Thu, 19 Apr 2007 20:51:09 +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 <0JGR00G01IXTYI00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Apr 2007 14:51:09 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGR00KATJ96TWS2@mail-amer.sun.com>; Thu, 19 Apr 2007 14:51:09 -0600 (MDT) Date: Thu, 19 Apr 2007 15:51:06 -0500 From: Rich Brown Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4627B853.6090902@sun.com> Sender: Rich.Brown@sun.com To: Prakash Sangappa Cc: PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <4627D63A.3070108@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627B853.6090902@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1470 Prakash Sangappa wrote: > Rich Brown wrote: >> >> >> PSARC/2007/124 Strong Type-Checking for VFS Operation Registration >> Mechanism >> >> When a developer attempts to compile an unbundled file system >> then s/he will get compilation errors due to the mismatch in the >> signatures for the vnode operations. >> >> Once the signatures are updated and the file system is recompiled, >> then the new VFSDEF_VERSION number will be picked up and the file >> system kernel module will be allowed to load. >> > > What about versioning vnode operations? We can have monitor type modules > which > can define vnode operations but do not necessarily have to define a > vfsdef_t. > These modules can intercept vnode operations via FEM. So, bumping up just > the VFSDEF_VERSION will not be enough to recognize a monitor type module > which could be using the older VOP interfaces. > > We will need a mechanism to version the vnode ops separately from VFS > operations > since there is no version number member defined in the > 'fs_operation_def_t' VOP names > template. > > -Prakash. > Long, long ago there was a suggestion of having multiple versions of VFS/vnode ops. The ARC strongly discouraged that. There are some technical issues with using FEM for this. We can discuss that offline. As I've stated, I think it would a worthy project for a team to take on the problem of how to evolve the VFS/vnode interface. That's not what this project is doing. Rich From Rich.Brown@sun.com Thu Apr 19 13:56:56 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 l3JKuurI013298 for ; Thu, 19 Apr 2007 13:56:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3JKuCmd001175; Thu, 19 Apr 2007 13:56:12 -0700 (PDT) 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 <0JGR00005JHM9400@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 13:56:10 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00M5DJHLML20@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 13:56:09 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JKu9jm000041; Thu, 19 Apr 2007 20:56:09 +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 <0JGR00J01JE7RD00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Thu, 19 Apr 2007 14:56:09 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGR00JPUJHG4464@mail-amer.sun.com>; Thu, 19 Apr 2007 14:56:07 -0600 (MDT) Date: Thu, 19 Apr 2007 15:56:04 -0500 From: Rich Brown Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4627CB59.9020805@Sun.COM> Sender: Rich.Brown@sun.com To: Frank Van Der Linden , Bart Smaalders Cc: Calum.Mackay@sun.com, PSARC-EXT@sun.com Message-id: <4627D764.1090200@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627A511.4050409@Sun.Com> <4627ACF8.2060709@Sun.COM> <4627CB59.9020805@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 491 Frank Van Der Linden wrote: > Bart Smaalders wrote: >> >> What third party filesystems are available for OpenSolaris? > OpenAFS has been mentioned.. also, hgfs (hostfs) for VMware. > > Not that I think it's a huge issue if they break with the next minor > release, I just wanted to mention it :) > > - Frank > To add to the list that Bart asked for, there's the FUSE project on opensolaris also. I have a call into one of the community leaders to discuss the potential impact. Rich From jek3@sun.com Thu Apr 19 14:11:56 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 l3JLBt4P014066 for ; Thu, 19 Apr 2007 14:11:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3JLAsdt016201; Fri, 20 Apr 2007 05:11:04 +0800 (SGT) 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 <0JGR00103K6E0700@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 14:11:02 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00MKDK6DMK30@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 14:11:01 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l3JLAtm5514741; Thu, 19 Apr 2007 14:11:00 -0700 (PDT) Date: Thu, 19 Apr 2007 11:09:48 -1000 From: Joseph Kowalski Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4627D53F.1060800@Sun.Com> To: John Plocher Cc: Rich Brown , PSARC-EXT@sun.com, Calum.Mackay@sun.com Message-id: <4627DA9C.90008@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627A511.4050409@Sun.Com> <4627B9E6.9030605@Sun.COM> <4627D53F.1060800@Sun.Com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1940 John Plocher wrote: > Rich Brown wrote: >> There are ideas for evolving the VFS interface, particularly in the face >> of Solaris updates, but those are still in the brainstorming stage and >> that work has not been funded. > > For various reasons (not all technical), Sun has not been able to > bring a project to create and expose a public VFS interface to > fruition. This history implies that such a project isn't trivial. > Nevertheless, it is an obviously needed and worthwhile thing to > do. I have a little different historical recollection. Its not that the project is that hard (after all, it could just be the production of a number of man pages). Its that there always seems to be a project on the horizon which makes us want to keep it Private. "Stacking VNodes" was one such project. I'm sure there were others, but their names escape me. (Note: That's private as in Solaris or OpenSolaris, not as in Sun.) > Any takers to start and lead a new Project to do this? Not to dampen the enthusiasm, but I think such a project is more political than technical. We already have a fairly nicely versioned interface, we just don't want to commit to it (Rich can correct me if appropriate, and considering he was lobbying for resources, it may be appropriate). Part of this is also motivation, as similar concerns were expressed about the DDI, which was much less "clean" (IMHO) when released. In the case of device drivers, we'd hoped for the number of non-Sun (or OpenSolaris) consumers to be well into double digits. For file systems? One hand should suffice for the enumeration with enough fingers left over for interesting hand gestures. That said, I'll give my push.... Anyone want to port ext3 to Solaris? Anyone want to port NTFS to Solaris? Probably not that important to most people, but I personally have many multiboot machines and looking at one OS directly from another is really cool for me. - jek3 From Sarah.Jelinek@sun.com Thu Apr 19 14:19:10 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 l3JLJ9JT014233 for ; Thu, 19 Apr 2007 14:19:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l3JLILkf018927; Fri, 20 Apr 2007 05:18:22 +0800 (SGT) 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 <0JGR0010TKILLA00@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 14:18:21 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JGR00MPRKIKMK40@nwk-avmta-2.sfbay.sun.com>; Thu, 19 Apr 2007 14:18:21 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3JLIKAm008888; Thu, 19 Apr 2007 21:18:20 +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 <0JGR00G01KE1GW00@mail-amer.sun.com> (original mail from Sarah.Jelinek@Sun.COM); Thu, 19 Apr 2007 15:18:20 -0600 (MDT) Received: from [192.9.61.158] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGR006SUKIJHQ6Y@mail-amer.sun.com>; Thu, 19 Apr 2007 15:18:20 -0600 (MDT) Date: Thu, 19 Apr 2007 15:18:18 -0600 From: Sarah Jelinek Subject: Re: 2007/218 caller_context_t in all VOPs In-reply-to: <4627D764.1090200@Sun.COM> Sender: Sarah.Jelinek@sun.com To: Rich Brown Cc: Frank Van Der Linden , Bart Smaalders , PSARC-EXT@sun.com, Calum.Mackay@sun.com Reply-to: Sarah.Jelinek@sun.com Message-id: <4627DC9A.6010504@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: <200704181724.l3IHO17o005688@ivrel.sfbay.sun.com> <46266702.7000809@Sun.COM> <4626897D.8060404@sun.com> <4626954C.1090304@Sun.COM> <4626A098.5030708@sun.com> <46276DC4.80208@Sun.COM> <4627A511.4050409@Sun.Com> <4627ACF8.2060709@Sun.COM> <4627CB59.9020805@Sun.COM> <4627D764.1090200@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070326) Status: RO Content-Length: 1250 Hi Rich and All, Rich Brown wrote: > > Frank Van Der Linden wrote: >> Bart Smaalders wrote: >>> >>> What third party filesystems are available for OpenSolaris? >> OpenAFS has been mentioned.. also, hgfs (hostfs) for VMware. >> >> Not that I think it's a huge issue if they break with the next minor >> release, I just wanted to mention it :) >> >> - Frank >> > > To add to the list that Bart asked for, there's the FUSE project > on opensolaris also. I have a call into one of the community leaders > to discuss the potential impact. FUSE is currently built outside of the ON consolidation, and the source is not integrated in to Solaris. So, we will track the changes made here, and in subsequent arc cases and make adjustments to the FUSE code as necessary. We are using these interfaces at this time without a contract, knowingly, since we are in the early stages of the port of FUSE to Solaris. We are tracking these changes and will adjust as they are available. Eventually we hope to not be a 3rd party fs since we want to integrate in to Solaris Nevada, but we are some time away from that. sarah **** > > Rich > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From Calum.Mackay@sun.com Wed Apr 25 12:11:29 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 l3PJBTNF017736 for ; Wed, 25 Apr 2007 12:11:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l3PJAZFA010409 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 25 Apr 2007 12:10:39 -0700 (PDT) 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 <0JH200717ILR6B00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Apr 2007 12:10:39 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JH20027CILP5I40@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Apr 2007 12:10:38 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3PJAarT014657 for ; Wed, 25 Apr 2007 19:10:36 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JH200E01IJHXD00@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Apr 2007 20:10:36 +0100 (BST) Received: from [192.168.254.1] ([62.24.230.83]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JH2005SRILNNNC8@d1-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Apr 2007 20:10:36 +0100 (BST) Date: Wed, 25 Apr 2007 20:10:34 +0100 From: Calum Mackay Subject: 2007/218 caller_context_t in all VOPs In-reply-to: <46241226.1080406@sun.com> Sender: Calum.Mackay@sun.com To: Calum Mackay Cc: psarc-ext@sun.com, Rich Brown Message-id: <462FA7AA.3000909@sun.com> Organization: Sun Microsystems 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: <46241226.1080406@sun.com> User-Agent: Thunderbird 3.0a1 (X11/20070425) Status: RO Content-Length: 127 This fast-track was approved during today's PSARC meeting. I have placed the final spec in the file: spec.txt cheers, calum.