From sacadmin Mon Mar 5 10:55:58 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l25ItwjB013759; Mon, 5 Mar 2007 10:55:58 -0800 (PST) Received: (from calum@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id l25ItwiF013755; Mon, 5 Mar 2007 10:55:58 -0800 (PST) Date: Mon, 5 Mar 2007 10:55:58 -0800 (PST) From: Calum Mackay Message-Id: <200703051855.l25ItwiF013755@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Subject: Strong Type-Checking for VFS Operation Registration Mechanism [PSARC/2007/124 Timeout: 03/14/2007] Status: RO Content-Length: 9636 Subject: PSARC FastTrack [03/14/2007]: Strong Type-Checking for VFS Operation Registration Mechanism Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Strong Type-Checking for VFS Operation Registration Mechanism 1.2. Name of Document Author/Supplier: Author: Rich Brown 1.3 Date of This Document: 05 March, 2007 4. Technical Description STRONGER TYPE-CHECKING FOR VNODE/VFS/FEM OPERATIONS Problem Description In Solaris 10, a mechanism to register vnode/vfs/fem operations was introduced as part of the File System Interfaces project (PSARC/2001/679). This operation registration mechanism provided the flexibility to add new vnode/vfs operations without requiring all file systems to be aware of the new operation. The downside of this was that strong type-checking of the operation signatures could not be done. Brief History The solution that was considered for the original implementation of the operation registration mechanism was to use C99's "designated initializer" feature. (This is briefly but incompletely described in section 2.1.3.1 "Alternative Implementations Considered" in the functional spec for PSARC/2001/679.) The implementation requires a union containing all the vnode and vfs operations including their full signatures (what each function returns and the type of each of the functions arguments). Next, each of the operation definition tables would be updated such that the implemented vnode/vfs operation would be initialized with a designated type from the union. For example: const fs_operation_def_t xxx_vnodeops_template[] = { { VOPNAME_OPEN, .vop_open = xxx_open }, { VOPNAME_CLOSE, .vop_close = xxx_close }, ... }; Unfortunately, the compiler used for Solaris 10 did not support this feature so that alternative could not be implemented at that time. But the Good News is... The good news is that the current compiler for Solaris Nevada *does* support "designated initializers" and its use for vnode/vfs/fem/fsem operations has been successfully prototyped. (In fact, several inconsistencies in vnode operation definitions were found in changes that were added since Solaris 10. Change requests have been filed and have since been fixed as a result of that discovery.) Proposed Solution The solution is relatively simple although it touches every file that uses the operation registration facilities (around 90 files). 1) Change names of vsop_* to femop_* and vfsop_* to fsemop_* in sys/fem.h and common/fs/fem.c This is mostly cosmetic, but will make it easier for developers of file/filesystem monitors to remember the names of the routines. For example, femop_open and fsemop_mount versus vsop_open and vfsop_mount. These names are currently project private since no one else would need to use them. They will now be consolidation private since anyone in the consolidation could develop a monitor. There are currently no consumers of this outside the ON consolidation. 2) Extract the contents (structure members) of each of the following structures and create a #define to represent them: vnodeops_t or "struct vnodeops" --> VNODE_OPS vfsops_t or "struct vfsops --> VFS_OPS fem_t or "struct fem" --> FEM_OPS fsem_t or "struct fsem" --> FSEM_OPS This is so that we can keep the signatures of each set of routines in one place and use the list in the structure as well as the union (see below). In other words, if VNODE_OPS contains the list of function prototypes for the vnodeops structure, we would have: sys/vnode.h: #define VNODE_OPS \ int (*vop_open)(vnode_t **, int, cred_t *); \ int (*vop_close)(vnode_t *, int, int, offset_t, cred_t *); \ ... int (*vop_vnevent)(vnode_t *, vnevent_t); typedef struct vnodeops { const char *vnop_name; VNODE_OPS } vnodeops_t; Similar changes would be made as described above for sys/vfs.h (VFS_OPS, vfsops_t) and sys/fem.h (FEM_OPS, fem_t, FSEM_OPS, fsem_t). 2) Create a new union and typedef, fs_func/fs_func_p, of all vop, vfsop, femop, fsemop routines: sys/vfs_opreg.h: typedef union fs_func { fs_generic_func_p fs_generic; /* Generic signature */ int (*error)(); /* Signature of error func */ VFS_OPS /* All vfs op signatures */ VNODE_OPS /* All vnode op signatures */ FEM_OPS /* All fem op signatures */ FSEM_OPS /* All fsem op signatures */ } fs_func_p; 3) Move all operation registration related declarations from sys/vnode.h and sys/vfs.h to a separate header file: (This is to avoid circular dependencies on the header files. 4) Update all file systems to include , where appropriate, and modify all fs_operation_def_t template arrays to use "designated initializers". Using the example above: const fs_operation_def_t xxx_vnodeops_template[] = { { VOPNAME_OPEN, .vop_open = xxx_open }, { VOPNAME_CLOSE, .vop_close = xxx_close }, ... }; So, What Does This Mean For Unbundled File System Developers? At a bare minimum, file system developers will have to add the following to any file that uses the operation registration mechanism: #include No further changes are required, but that means the file system does not take advantage of the strong type-checking described by these changes. The change that takes advantage of the strong type-checking is described by #4 above. All fs_operation_def_t template arrays would be modified to use "designated initializers". So, an fs_operation_def_t array that looks like this today: const fs_operation_def_t xxx_vnodeops_template[] = { { VOPNAME_OPEN, xxx_open }, { VOPNAME_CLOSE, xxx_close }, ... }; ...would be modified to look like this: const fs_operation_def_t xxx_vnodeops_template[] = { { VOPNAME_OPEN, .vop_open = xxx_open }, { VOPNAME_CLOSE, .vop_close = xxx_close }, ... }; Communication to 3rd Party FS Vendors As I have in the past, I will take responsibility for informing the contacts for 3rd party file systems. Just in case my PowerBall lottery numbers match this week, here is the contact information: Mail alias: unbundled-fs-developers@sun.com Exported Interface Table +-----------------------+---------------+---------------+----------------------+ | Interface Name | Proposed | Specified in | Comments | | | Stability | What Document?| | +=======================+===============+===============+======================+ | | Consolidation | This document | Contains new fs_func | | | Private | | union plus interface | | | | | declarations moved | | | | | from sys/vnode.h and | | | | | sys/vfs.h | +-----------------------+---------------+---------------+----------------------+ | union fs_func | Consolidation | This document | See #2 in "Proposed | | fs_func_p (typedef) | Private | | Solution" section | +-----------------------+---------------+---------------+----------------------+ | femop_open | Consolidation | This document.| These names were | | femop_close | Private | See #1 in | changed from vsop_*. | | femop_read | | "Proposed | Previously, they were| | femop_write | | Solution" | considered "Project | | femop_ioctl | | above | Private" but are now | | femop_setfl | | | exposed within the | | femop_getattr | | | consolidation to any | | femop_setattr | | | project that would | | femop_access | | | use FEM. | | femop_lookup | | | | | femop_create | | | Note that the only | | femop_remove | | | reason to expose | | femop_link | | | these is for their | | femop_rename | | | use as "designated | | femop_mkdir | | | initializers" | | femop_rmdir | | | | | femop_readdir | | | | | femop_symlink | | | | | femop_readlink | | | | | femop_fsync | | | | | femop_inactive | | | | | femop_fid | | | | | femop_rwlock | | | | | femop_rwunlock | | | | | femop_seek | | | | | femop_cmp | | | | | femop_frlock | | | | | femop_space | | | | | femop_realvp | | | | | femop_getpage | | | | | femop_putpage | | | | | femop_map | | | | | femop_addmap | | | | | femop_delmap | | | | | femop_poll | | | | | femop_dump | | | | | femop_pathconf | | | | | femop_pageio | | | | | femop_dumpctl | | | | | femop_dispose | | | | | femop_setsecattr | | | | | femop_getsecattr | | | | | femop_shrlock | | | | | femop_vnevent | | | | +-----------------------+---------------+---------------+----------------------+ | fsemop_mount | Consolidation | This document.| As above, except | | fsemop_unmount | Private | See #1 of | changed from vfsop_* | | fsemop_root | | "Proposed | | | fsemop_statvfs | | Solution" | | | fsemop_sync | | above. | | | fsemop_vget | | | | | fsemop_mountroot | | | | | fsemop_freevfs | | | | | fsemop_vnstate | | | | +-----------------------+---------------+---------------+----------------------+ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Mon Mar 5 10:58:44 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l25IwiWi013831 for ; Mon, 5 Mar 2007 10:58:44 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l25Iwh64023561 for ; Mon, 5 Mar 2007 10:58:43 -0800 (PST) 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 l25IwbKt010866 for ; Mon, 5 Mar 2007 18:58:38 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 <0JEG00A011U89G00@d1-emea-10.sun.com> (original mail from Calum.Mackay@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 05 Mar 2007 18:58:37 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEG0024E21P5RFD@d1-emea-10.sun.com> for psarc@sac.sfbay.sun.com; Mon, 05 Mar 2007 18:58:37 +0000 (GMT) Date: Mon, 05 Mar 2007 18:58:37 +0000 From: Calum Mackay Subject: 2007/124 Strong Type-Checking for VFS Operation Registration Mechanism Sender: Calum.Mackay@Sun.COM To: psarc@sac.sfbay.sun.com, Rich Brown Message-id: <45EC685D.2050308@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0b2 (X11/20070130) Status: RO Content-Length: 11945 I'm sponsoring the following fast-track for Rich Brown. The timer is set to next Weds, 14th March. The case seeks Minor binding. cheers, calum. STRONGER TYPE-CHECKING FOR VNODE/VFS/FEM OPERATIONS Problem Description In Solaris 10, a mechanism to register vnode/vfs/fem operations was introduced as part of the File System Interfaces project (PSARC/2001/679). This operation registration mechanism provided the flexibility to add new vnode/vfs operations without requiring all file systems to be aware of the new operation. The downside of this was that strong type-checking of the operation signatures could not be done. Brief History The solution that was considered for the original implementation of the operation registration mechanism was to use C99's "designated initializer" feature. (This is briefly but incompletely described in section 2.1.3.1 "Alternative Implementations Considered" in the functional spec for PSARC/2001/679.) The implementation requires a union containing all the vnode and vfs operations including their full signatures (what each function returns and the type of each of the functions arguments). Next, each of the operation definition tables would be updated such that the implemented vnode/vfs operation would be initialized with a designated type from the union. For example: const fs_operation_def_t xxx_vnodeops_template[] = { { VOPNAME_OPEN, .vop_open = xxx_open }, { VOPNAME_CLOSE, .vop_close = xxx_close }, ... }; Unfortunately, the compiler used for Solaris 10 did not support this feature so that alternative could not be implemented at that time. But the Good News is... The good news is that the current compiler for Solaris Nevada *does* support "designated initializers" and its use for vnode/vfs/fem/fsem operations has been successfully prototyped. (In fact, several inconsistencies in vnode operation definitions were found in changes that were added since Solaris 10. Change requests have been filed and have since been fixed as a result of that discovery.) Proposed Solution The solution is relatively simple although it touches every file that uses the operation registration facilities (around 90 files). 1) Change names of vsop_* to femop_* and vfsop_* to fsemop_* in sys/fem.h and common/fs/fem.c This is mostly cosmetic, but will make it easier for developers of file/filesystem monitors to remember the names of the routines. For example, femop_open and fsemop_mount versus vsop_open and vfsop_mount. These names are currently project private since no one else would need to use them. They will now be consolidation private since anyone in the consolidation could develop a monitor. There are currently no consumers of this outside the ON consolidation. 2) Extract the contents (structure members) of each of the following structures and create a #define to represent them: vnodeops_t or "struct vnodeops" --> VNODE_OPS vfsops_t or "struct vfsops --> VFS_OPS fem_t or "struct fem" --> FEM_OPS fsem_t or "struct fsem" --> FSEM_OPS This is so that we can keep the signatures of each set of routines in one place and use the list in the structure as well as the union (see below). In other words, if VNODE_OPS contains the list of function prototypes for the vnodeops structure, we would have: sys/vnode.h: #define VNODE_OPS \ int (*vop_open)(vnode_t **, int, cred_t *); \ int (*vop_close)(vnode_t *, int, int, offset_t, cred_t *); \ ... int (*vop_vnevent)(vnode_t *, vnevent_t); typedef struct vnodeops { const char *vnop_name; VNODE_OPS } vnodeops_t; Similar changes would be made as described above for sys/vfs.h (VFS_OPS, vfsops_t) and sys/fem.h (FEM_OPS, fem_t, FSEM_OPS, fsem_t). 2) Create a new union and typedef, fs_func/fs_func_p, of all vop, vfsop, femop, fsemop routines: sys/vfs_opreg.h: typedef union fs_func { fs_generic_func_p fs_generic; /* Generic signature */ int (*error)(); /* Signature of error func */ VFS_OPS /* All vfs op signatures */ VNODE_OPS /* All vnode op signatures */ FEM_OPS /* All fem op signatures */ FSEM_OPS /* All fsem op signatures */ } fs_func_p; 3) Move all operation registration related declarations from sys/vnode.h and sys/vfs.h to a separate header file: (This is to avoid circular dependencies on the header files. 4) Update all file systems to include , where appropriate, and modify all fs_operation_def_t template arrays to use "designated initializers". Using the example above: const fs_operation_def_t xxx_vnodeops_template[] = { { VOPNAME_OPEN, .vop_open = xxx_open }, { VOPNAME_CLOSE, .vop_close = xxx_close }, ... }; So, What Does This Mean For Unbundled File System Developers? At a bare minimum, file system developers will have to add the following to any file that uses the operation registration mechanism: #include No further changes are required, but that means the file system does not take advantage of the strong type-checking described by these changes. The change that takes advantage of the strong type-checking is described by #4 above. All fs_operation_def_t template arrays would be modified to use "designated initializers". So, an fs_operation_def_t array that looks like this today: const fs_operation_def_t xxx_vnodeops_template[] = { { VOPNAME_OPEN, xxx_open }, { VOPNAME_CLOSE, xxx_close }, ... }; ...would be modified to look like this: const fs_operation_def_t xxx_vnodeops_template[] = { { VOPNAME_OPEN, .vop_open = xxx_open }, { VOPNAME_CLOSE, .vop_close = xxx_close }, ... }; Communication to 3rd Party FS Vendors As I have in the past, I will take responsibility for informing the contacts for 3rd party file systems. Just in case my PowerBall lottery numbers match this week, here is the contact information: Mail alias: unbundled-fs-developers@sun.com Exported Interface Table +-----------------------+---------------+---------------+----------------------+ | Interface Name | Proposed | Specified in | Comments | | | Stability | What Document?| | +=======================+===============+===============+======================+ | | Consolidation | This document | Contains new fs_func | | | Private | | union plus interface | | | | | declarations moved | | | | | from sys/vnode.h and | | | | | sys/vfs.h | +-----------------------+---------------+---------------+----------------------+ | union fs_func | Consolidation | This document | See #2 in "Proposed | | fs_func_p (typedef) | Private | | Solution" section | +-----------------------+---------------+---------------+----------------------+ | femop_open | Consolidation | This document.| These names were | | femop_close | Private | See #1 in | changed from vsop_*. | | femop_read | | "Proposed | Previously, they were| | femop_write | | Solution" | considered "Project | | femop_ioctl | | above | Private" but are now | | femop_setfl | | | exposed within the | | femop_getattr | | | consolidation to any | | femop_setattr | | | project that would | | femop_access | | | use FEM. | | femop_lookup | | | | | femop_create | | | Note that the only | | femop_remove | | | reason to expose | | femop_link | | | these is for their | | femop_rename | | | use as "designated | | femop_mkdir | | | initializers" | | femop_rmdir | | | | | femop_readdir | | | | | femop_symlink | | | | | femop_readlink | | | | | femop_fsync | | | | | femop_inactive | | | | | femop_fid | | | | | femop_rwlock | | | | | femop_rwunlock | | | | | femop_seek | | | | | femop_cmp | | | | | femop_frlock | | | | | femop_space | | | | | femop_realvp | | | | | femop_getpage | | | | | femop_putpage | | | | | femop_map | | | | | femop_addmap | | | | | femop_delmap | | | | | femop_poll | | | | | femop_dump | | | | | femop_pathconf | | | | | femop_pageio | | | | | femop_dumpctl | | | | | femop_dispose | | | | | femop_setsecattr | | | | | femop_getsecattr | | | | | femop_shrlock | | | | | femop_vnevent | | | | +-----------------------+---------------+---------------+----------------------+ | fsemop_mount | Consolidation | This document.| As above, except | | fsemop_unmount | Private | See #1 of | changed from vfsop_* | | fsemop_root | | "Proposed | | | fsemop_statvfs | | Solution" | | | fsemop_sync | | above. | | | fsemop_vget | | | | | fsemop_mountroot | | | | | fsemop_freevfs | | | | | fsemop_vnstate | | | | +-----------------------+---------------+---------------+----------------------+ From sacadmin Mon Mar 5 11:00:58 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l25J0w6X013851 for ; Mon, 5 Mar 2007 11:00:58 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l25J0vax006489 for ; Mon, 5 Mar 2007 11:00:58 -0800 (PST) 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 l25J0qGG010963 for ; Mon, 5 Mar 2007 19:00:52 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 <0JEG0060123PGT00@d1-emea-09.sun.com> (original mail from Calum.Mackay@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 05 Mar 2007 19:00:52 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEG00HVI25G13M4@d1-emea-09.sun.com> for PSARC@sac.sfbay.sun.com; Mon, 05 Mar 2007 19:00:52 +0000 (GMT) Date: Mon, 05 Mar 2007 19:00:52 +0000 From: Calum Mackay Subject: Re: Strong Type-Checking for VFS Operation Registration Mechanism [PSARC/2007/124 Timeout: 03/14/2007] In-reply-to: <200703051855.l25ItwiF013755@sac.sfbay.sun.com> Sender: Calum.Mackay@Sun.COM To: PSARC@sac.sfbay.sun.com Message-id: <45EC68E4.5000601@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200703051855.l25ItwiF013755@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070130) Status: RO Content-Length: 295 Calum Mackay wrote: > Subject: PSARC FastTrack [03/14/2007]: Strong Type-Checking for VFS Operation Registration Mechanism sigh; sac_nextcase seems to have a mind of its own. Please reply to the other email I've sent on this, which has a Cc including the submitter. thanks much. cheers, c. From sacadmin Mon Mar 5 11:01:41 2007 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l25J1fkl013867; Mon, 5 Mar 2007 11:01:41 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l25J1dD17935; Mon, 5 Mar 2007 11:01:39 -0800 (PST) Message-ID: <45EC6912.5010302@sun.com> Date: Mon, 05 Mar 2007 11:01:38 -0800 From: Scott Rotondo User-Agent: Thunderbird 2.0b2 (X11/20070129) MIME-Version: 1.0 To: Calum Mackay CC: PSARC@sac.sfbay.sun.com Subject: Re: Strong Type-Checking for VFS Operation Registration Mechanism [PSARC/2007/124 Timeout: 03/14/2007] References: <200703051855.l25ItwiF013755@sac.sfbay.sun.com> In-Reply-To: <200703051855.l25ItwiF013755@sac.sfbay.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 380 Calum Mackay wrote: > The good news is that the current compiler for Solaris Nevada *does* > support "designated initializers" and its use for vnode/vfs/fem/fsem > operations has been successfully prototyped. Would it be correct to interpret this sentence to mean that *both* compilers used for Solaris Nevada (Sun Studio and gcc) support designated initializers? Scott From sacadmin Mon Mar 5 11:08:02 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l25J82nC013923 for ; Mon, 5 Mar 2007 11:08:02 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l25J81Gt010801 for ; Mon, 5 Mar 2007 11:08:01 -0800 (PST) Received: from 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 l25J7ttr012967 for ; Mon, 5 Mar 2007 19:07:55 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 <0JEG00E012AQ4Q00@d1-emea-10.sun.com> (original mail from Calum.Mackay@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 05 Mar 2007 19:07:55 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEG002BS2H65RGD@d1-emea-10.sun.com>; Mon, 05 Mar 2007 19:07:55 +0000 (GMT) Date: Mon, 05 Mar 2007 19:07:54 +0000 From: Calum Mackay Subject: Re: Strong Type-Checking for VFS Operation Registration Mechanism [PSARC/2007/124 Timeout: 03/14/2007] In-reply-to: <45EC6912.5010302@sun.com> Sender: Calum.Mackay@Sun.COM To: Scott Rotondo Cc: PSARC@sac.sfbay.sun.com, Rich Brown Message-id: <45EC6A8A.8060705@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200703051855.l25ItwiF013755@sac.sfbay.sun.com> <45EC6912.5010302@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070130) Status: RO Content-Length: 496 Scott Rotondo wrote: > Calum Mackay wrote: >> The good news is that the current compiler for Solaris Nevada *does* >> support "designated initializers" and its use for vnode/vfs/fem/fsem >> operations has been successfully prototyped. > > Would it be correct to interpret this sentence to mean that *both* > compilers used for Solaris Nevada (Sun Studio and gcc) support > designated initializers? I assume so; I've asked Rich to confirm (since he didn't see this question). cheers, c. From sacadmin Mon Mar 5 11:27:25 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l25JRPgI014300 for ; Mon, 5 Mar 2007 11:27:25 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l25JRPBq010906 for ; Mon, 5 Mar 2007 11:27:25 -0800 (PST) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l25JRPWS025206 for ; Mon, 5 Mar 2007 19:27:25 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 <0JEG0010138UN200@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 05 Mar 2007 12:27:25 -0700 (MST) Received: from [129.147.9.47] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEG006423DNBZT3@mail-amer.sun.com>; Mon, 05 Mar 2007 12:27:24 -0700 (MST) Date: Mon, 05 Mar 2007 13:27:22 -0600 From: Rich Brown Subject: Re: Strong Type-Checking for VFS Operation Registration Mechanism [PSARC/2007/124 Timeout: 03/14/2007] In-reply-to: <45EC6A8A.8060705@sun.com> Sender: Rich.Brown@Sun.COM To: Scott Rotondo Cc: Calum Mackay , PSARC@sac.sfbay.sun.com Message-id: <45EC6F1A.5020207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200703051855.l25ItwiF013755@sac.sfbay.sun.com> <45EC6912.5010302@sun.com> <45EC6A8A.8060705@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 776 Calum Mackay wrote: > Scott Rotondo wrote: >> Calum Mackay wrote: >>> The good news is that the current compiler for Solaris Nevada *does* >>> support "designated initializers" and its use for vnode/vfs/fem/fsem >>> operations has been successfully prototyped. >> >> Would it be correct to interpret this sentence to mean that *both* >> compilers used for Solaris Nevada (Sun Studio and gcc) support >> designated initializers? > > I assume so; I've asked Rich to confirm (since he didn't see this > question). > > cheers, > c. Thanks Calum... Hi Scott, Yes, both compilers support designated initializers and both will catch a problem. (In fact, I experimented with this in the S10 timeframe and gcc was already supporting "designated initializers".) Rich From sacadmin Mon Mar 5 12:44:52 2007 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l25KipXA016304 for ; Mon, 5 Mar 2007 12:44:52 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l25Kiog1026312; Mon, 5 Mar 2007 15:44:50 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l25Kiomt004071; Mon, 5 Mar 2007 15:44:50 -0500 (EST) Subject: Re: 2007/124 Strong Type-Checking for VFS Operation Registration Mechanism From: Bill Sommerfeld To: Calum Mackay Cc: psarc@sac.sfbay.sun.com, Rich Brown In-Reply-To: <45EC685D.2050308@sun.com> References: <45EC685D.2050308@sun.com> Content-Type: text/plain Date: Mon, 05 Mar 2007 15:44:49 -0500 Message-Id: <1173127489.3489.61.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2198 > #define VNODE_OPS \ > int (*vop_open)(vnode_t **, int, cred_t *); \ > int (*vop_close)(vnode_t *, int, int, offset_t, cred_t *); \ > ... > int (*vop_vnevent)(vnode_t *, vnevent_t); ... > sys/vfs_opreg.h: > > typedef union fs_func { > fs_generic_func_p fs_generic; /* Generic signature */ > int (*error)(); /* Signature of error func */ > VFS_OPS /* All vfs op signatures */ > VNODE_OPS /* All vnode op signatures */ > FEM_OPS /* All fem op signatures */ > FSEM_OPS /* All fsem op signatures */ > } fs_func_p; This borders on a code review style comment but addressing it looks like it might change the interface.. my experince with using preprocessor like this in C is that you may be better off leaving off the trailing ";" of the last field in the macro definition -- tools which operate on source files using partial understanding of C syntax (including emacs's C-mode automatic indentation or cstyle) have a better chance of getting the indentation correct if the macro invocations look like: typedef union fs_func { fs_generic_func_p fs_generic; /* Generic signature */ int (*error)(); /* Signature of error func */ VFS_OPS; /* All vfs op signatures */ VNODE_OPS; /* All vnode op signatures */ FEM_OPS; /* All fem op signatures */ FSEM_OPS; /* All fsem op signatures */ } fs_func_p; C permits extra semicolons in the middle of struct definitions, but compilers often warn about this; our compiler gives you a: "syntax-test.c", line 4: warning: syntax error: empty member declaration while gcc can be provoked into generating: syntax-test.c:4: warning: extra semicolon in struct or union specified From sacadmin Mon Mar 5 14:23:06 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l25MN69C019071 for ; Mon, 5 Mar 2007 14:23:06 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l25MN6pd014399 for ; Mon, 5 Mar 2007 14:23:06 -0800 (PST) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l25MN5GT002674 for ; Mon, 5 Mar 2007 22:23:05 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 <0JEG00A01B7CHD00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM) for psarc@sac.sfbay.sun.com; Mon, 05 Mar 2007 15:23:05 -0700 (MST) Received: from [129.147.9.47] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JEG008BBBIGJUB4@mail-amer.sun.com>; Mon, 05 Mar 2007 15:23:05 -0700 (MST) Date: Mon, 05 Mar 2007 16:23:04 -0600 From: Rich Brown Subject: Re: 2007/124 Strong Type-Checking for VFS Operation Registration Mechanism In-reply-to: <1173127489.3489.61.camel@thunk> Sender: Rich.Brown@Sun.COM To: Bill Sommerfeld Cc: psarc@sac.sfbay.sun.com Message-id: <45EC9848.5040801@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <45EC685D.2050308@sun.com> <1173127489.3489.61.camel@thunk> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 2510 Bill Sommerfeld wrote: >> #define VNODE_OPS \ >> int (*vop_open)(vnode_t **, int, cred_t *); \ >> int (*vop_close)(vnode_t *, int, int, offset_t, cred_t *); \ >> ... >> int (*vop_vnevent)(vnode_t *, vnevent_t); > ... >> sys/vfs_opreg.h: >> >> typedef union fs_func { >> fs_generic_func_p fs_generic; /* Generic signature */ >> int (*error)(); /* Signature of error func */ >> VFS_OPS /* All vfs op signatures */ >> VNODE_OPS /* All vnode op signatures */ >> FEM_OPS /* All fem op signatures */ >> FSEM_OPS /* All fsem op signatures */ >> } fs_func_p; > > This borders on a code review style comment but addressing it looks like > it might change the interface.. > > my experince with using preprocessor like this in C is that you may be > better off leaving off the trailing ";" of the last field in the macro > definition -- tools which operate on source files using partial > understanding of C syntax (including emacs's C-mode automatic > indentation or cstyle) have a better chance of getting the indentation > correct if the macro invocations look like: > > typedef union fs_func { > fs_generic_func_p fs_generic; /* Generic signature */ > int (*error)(); /* Signature of error func */ > VFS_OPS; /* All vfs op signatures */ > VNODE_OPS; /* All vnode op signatures */ > FEM_OPS; /* All fem op signatures */ > FSEM_OPS; /* All fsem op signatures */ > } fs_func_p; > > C permits extra semicolons in the middle of struct definitions, but > compilers often warn about this; our compiler gives you a: > > "syntax-test.c", line 4: warning: syntax error: empty member declaration > > while gcc can be provoked into generating: > > syntax-test.c:4: warning: extra semicolon in struct or union specified > Hi Bill, Yep, your suggestion is likely to be easier on other developer tools. I'll make the change snd see if anything complains. Unless you hear back from me to the contrary, consider it done. Thanks, Rich From sacadmin Wed Mar 28 09:14:04 2007 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2SGE4fB024390; Wed, 28 Mar 2007 09:14:04 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2SGE3Kx027153; Wed, 28 Mar 2007 12:14:03 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2SGE3V0025823; Wed, 28 Mar 2007 12:14:03 -0400 (EDT) Subject: Re: Strong Type-Checking for VFS Operation Registration Mechanism [PSARC/2007/124 Timeout: 03/14/2007] From: Bill Sommerfeld To: Calum Mackay Cc: PSARC@sac.sfbay.sun.com, Rich.Brown@sun.com In-Reply-To: <200703051855.l25ItwiF013755@sac.sfbay.sun.com> References: <200703051855.l25ItwiF013755@sac.sfbay.sun.com> Content-Type: text/plain Date: Wed, 28 Mar 2007 12:14:02 -0400 Message-Id: <1175098442.25315.62.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 204 Is there any reason (other than "sac_nextcase doesn't ask yet") why this case was filed as "closed" ? I've seen a couple requests for the technical content of this case in particular. - Bill From sacadmin Sun Apr 1 15:45:34 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l31MjYSY011226; Sun, 1 Apr 2007 15:45:34 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l31Mj3g7025061; Sun, 1 Apr 2007 15:45:04 -0700 (PDT) Received: from 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 l31Mivti014120; Sun, 1 Apr 2007 22:44:58 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 <0JFU00501C4QMX00@d1-emea-10.sun.com> (original mail from Calum.Mackay@Sun.COM); Sun, 01 Apr 2007 23:44:57 +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 <0JFU00L31CIWI7LR@d1-emea-10.sun.com>; Sun, 01 Apr 2007 23:44:57 +0100 (BST) Date: Sun, 01 Apr 2007 23:44:56 +0100 From: Calum Mackay Subject: Re: Strong Type-Checking for VFS Operation Registration Mechanism [PSARC/2007/124 Timeout: 03/14/2007] In-reply-to: <1175098442.25315.62.camel@thunk> Sender: Calum.Mackay@Sun.COM To: Bill Sommerfeld Cc: Calum Mackay , PSARC@sac.sfbay.sun.com, Rich.Brown@Sun.COM Message-id: <461035E8.2090401@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200703051855.l25ItwiF013755@sac.sfbay.sun.com> <1175098442.25315.62.camel@thunk> User-Agent: Thunderbird 3.0a1 (X11/20070322) Status: RO Content-Length: 376 hi Bill, > Is there any reason (other than "sac_nextcase doesn't ask yet") why this > case was filed as "closed" ? that, and force of habit, I fear; apologies. Is it the case (ahem) that all new cases should be "open" by default, or including some statement as to why they're not "open"? I don't get that impression from many of the cases filed recently... cheers, c.