VFSFT_SYSATTR_VIEWS [PSARC/2008/588 Self Review]
I'm sponsoring this for Janice Chang. This case adds a new VFS Feature, VFSFT_SYSATTR_VIEWS, which is registered when a file system supports the extended attribute files that describe extensible system attributes (a.k.a. views). This case is an extension of the Extensible Attribute Interface (PSARC 2007/315) which was approved with minor binding. Since this case simply allows the (VFS) registration of an existing interface, I'm filing this as Closed Approved Automatic. If anyone disagrees, let me know and I'll promote it to a fast track. Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: VFSFT_SYSATTR_VIEWS 1.2. Name of Document Author/Supplier: Author: Janice Chang 1.3 Date of This Document: 17 September, 2008 4. Technical Description PSARC 2007/315 (Extensible Attribute Interfaces) introduced a set of interfaces to retrieve and manipulate extensible system attributes on file objects. Extensible system attributes (also known as system attributes) were introduced specifically to support the CIFS service, which requires support for DOS attributes (PSARC 2006/715). One of the interfaces described by this case is an extensible vattr_t structure called xvattr_t. It is used with VOP_SETATTR()/VOP_GETATTR() to set/retrieve the new system attributes. File systems that support this interface communicate this to consumers by using the VFS Feature Registration facility (PSARC 2007/227) to register VFSFT_XVATTR. Another interface described by the Extensible Attribute Interfaces case is called a view. Each view exposes a group of system attributes as an extended attribute file whose name begins with SUNWattr_ (e.g., SUNWattr_rw for modifiable attributes and SUNWattr_ro for attributes that cannot be modified). These views are used to accomodate existing extended attribute aware utilities. File systems that support modifiable system attributes use both the xvattr_t and views interface. However, some file systems (tmpfs, ufs) support only non-modifiable system attributes (e.g., FSID) which are exposed only through a read-only view (SUNWattr_ro). Unfortunately, the VFSFT_XVATTR feature was set on these file systems to indicate support for system attributes. Overloading VFSFT_XVATTR meant that consumers would attempt to retrieve system attributes by using xvattr_t with VOP_GETATTR(), which would result in an error. In order to remedy this problem, a new VFS Feature is introduced-- VFSFT_SYSATTR_VIEWS--which denotes support specifically for the view interface for extensible system attributes. All ON file systems that support views will be modified to register the VFSFT_SYSATTR_VIEWS feature and only those ON file systems that support the xvattr_t interface will register VFSFT_XVATTR. Consumers (in particular, the CIFS service) will be able to reliably determine which interface is available to manipulate the system attributes of a file. This change is Consolidation Private and will be communicated to the unbundled file system teams (internal and external). 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
Remove /usr/bin/printf from PSARC case 2008 094 [PSARC/2008/589 Self Review]
I am sponsoring this case for Roland Mainz (an OpenSolaris contributor) and April Chin (acting as sponsor for this work). I believe it qualifies for closed approved automatic status. If a PSARC member disagrees, let me know and I will upgrade it to a fast-track case. Sincerely, Don Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Remove /usr/bin/printf from PSARC case 2008 094 1.2. Name of Document Author/Supplier: Author: Donald Cragun 1.3 Date of This Document: 17 September, 2008 4. Technical Description This case updates PSARC/2008/094 (ksh93 Update 1). While implementing PSARC/2008/094, which (among other things) planned to replace /usr/bin/printf with a link to the ATT AST printf, the project team found some irregularities in standards conformance in both the default printf() function in libc and in the behavior of /usr/bin/printf. Since some of these issues may involve official interpretation requests against the POSIX Standards and the Single UNIX Specifications, they may take a long time to resolve. Therefore, this case removes the changes to /usr/bin/printf that were documented in PSARC/2008/094 from the deliverables provided by that case so PSARC/2008/094 changes can be integrated in a timely manner. Since the current /usr/bin/printf will not be changed by this case, there are no backwards compatibility issues. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
Remove /usr/bin/printf from PSARC case 2008 094 [PSARC/2008/589 Self Review]
I concur that this is an automatic approval case. In fact, you probably could have just done it as an update to 2008/094 directly. That said, out of curiosity, where do the implementations differ such that ksh93's version can't stand as a replacement? -- Garrett Don Cragun wrote: I am sponsoring this case for Roland Mainz (an OpenSolaris contributor) and April Chin (acting as sponsor for this work). I believe it qualifies for closed approved automatic status. If a PSARC member disagrees, let me know and I will upgrade it to a fast-track case. Sincerely, Don Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Remove /usr/bin/printf from PSARC case 2008 094 1.2. Name of Document Author/Supplier: Author: Donald Cragun 1.3 Date of This Document: 17 September, 2008 4. Technical Description This case updates PSARC/2008/094 (ksh93 Update 1). While implementing PSARC/2008/094, which (among other things) planned to replace /usr/bin/printf with a link to the ATT AST printf, the project team found some irregularities in standards conformance in both the default printf() function in libc and in the behavior of /usr/bin/printf. Since some of these issues may involve official interpretation requests against the POSIX Standards and the Single UNIX Specifications, they may take a long time to resolve. Therefore, this case removes the changes to /usr/bin/printf that were documented in PSARC/2008/094 from the deliverables provided by that case so PSARC/2008/094 changes can be integrated in a timely manner. Since the current /usr/bin/printf will not be changed by this case, there are no backwards compatibility issues. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
Remove /usr/bin/printf from PSARC case 2008 094 [PSARC/2008/589Self Review]
Garrett D'Amore wrote: -- Garrett Don Cragun wrote: I am sponsoring this case for Roland Mainz (an OpenSolaris contributor) and April Chin (acting as sponsor for this work). I believe it qualifies for closed approved automatic status. If a PSARC member disagrees, let me know and I will upgrade it to a fast-track case. Sincerely, Don Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Remove /usr/bin/printf from PSARC case 2008 094 1.2. Name of Document Author/Supplier: Author: Donald Cragun 1.3 Date of This Document: 17 September, 2008 4. Technical Description This case updates PSARC/2008/094 (ksh93 Update 1). While implementing PSARC/2008/094, which (among other things) planned to replace /usr/bin/printf with a link to the ATT AST printf, the project team found some irregularities in standards conformance in both the default printf() function in libc and in the behavior of /usr/bin/printf. Since some of these issues may involve official interpretation requests against the POSIX Standards and the Single UNIX Specifications, they may take a long time to resolve. Therefore, this case removes the changes to /usr/bin/printf that were documented in PSARC/2008/094 from the deliverables provided by that case so PSARC/2008/094 changes can be integrated in a timely manner. Since the current /usr/bin/printf will not be changed by this case, there are no backwards compatibility issues. I concur that this is an automatic approval case. In fact, you probably could have just done it as an update to 2008/094 directly. Erm... the idea is to defer this part to a later putback when the issues have been resolved. The problem is that we don't have time anymore for _any_ discussions around the /usr/bin/printf since the code for PSARC/2008/094 must be ready by Friday (_last_ _date_). That said, out of curiosity, where do the implementations differ such that ksh93's s/ksh93/AST/ , ksh93 only offers the AST version of printf as builtin command version can't stand as a replacement? It's the precision option of %s - does it count in whole charatcers (where character means multi-byte character (like all other ksh88/ksh93/bash2/bash3 string operators do)), screen columns (since _some_ multibyte characters occupy more than one screen column) or bytes. The ksh93 builtin originally used whole characters but the POSIX/SUS standards indirectly define bytes (without having any leeway right now to allow whole characters) and the Solaris command seems to use (accidently ?) screen columns (where I doubt whether this makes sense). In the meantime the ksh93 builtin has been changed to use bytes as defined by POSIX/SUS and we're now trying to investigate two things: 1. Why Solaris's /usr/bin/printf uses screen columns ? 2. How can we get a |printf()| formatting option for whole characters (%s's precision option counting in bytes isn't very healthy for multibyte characters) ? We're currently digging around to get an answer for [1] but we don't have _any_ time anymore to hold-off the other parts of PSARC/2008/094 for that - people need the updated/fixed ksh93 _BADLY_, preferable checked-in yesterday or the day before that. Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
