Don Cragun wrote: > On Thu, 07 Jun 2007 16:33:00 -0600, Mark Shellenbaum wrote: >> Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack >> timeout > 06/06/2007] >> Don Cragun wrote: >>> The case materials say that this case will be allowing extensible >>> attributes to be added presumably by any vendor/application writer that >>> wants to add an attribute to a file. Discussion on this topic has >>> implied that there will be no registration of extensible attributes >>> because registration is complex, slow, etc. The case materials also >>> state that utilities, including ls(1), will be modified to display all >>> of the attributes associated with a file. >>> >>> Since there is no registration of attributes and none of the new >>> interfaces being added here provide a textual description of the >>> attributes, how is ls supposed to be able to display the attributes (at >>> least those that are not included in this case) in any manner that will >>> have any meaning to someone looking at the output from ls? >>> >>> Is it really going to help anyone if all ls can say is something like >>> >>> -rw-r--r-- (--SA--------) 1 dwc staff 5771 Jun 7 11:35 file >>> Unknown Attributes: 0x00647763:00000002, 0x00647763:00000008, > 0x00647763:00000040, 0x00647763:00000800 >>> when it encounters unknown extensible attributes? >>> >>> - Don >>> >> >> Although this case allows for system attributes to be added, it >> does not presume that anyone can add any system attribute without >> ARC approval. As stated in an earlier e-mail to Glenn: >> >> Changes to support new system attributes will touch >> enough to justify PSARC attention. > > This sort of works for "system" attributes. PSARC becomes the > registration authority for "system" extensible attributes, and any case > coming to PSARC for a new system attribute will have to include an > update to [at least] ls(1). It doesn't work for non-"system" > attributes. >
This case is specific to system attributes. Except for exposing the two extended attribute files (SUNWattr_rw and SUNWattr_ro) which are really views into the optional system attributes, the project team does not desire to change any of the policy from PSARC 1999/209 (Extended File Attributes). >> Also, please see section 4.4 Managing Change in the Attribute Space. >> >> As for displaying the attributes via 'ls', there is a separate >> effort by the Utilities Group to tackle this problem. There are >> two things that this project team can suggest: >> >> - Project teams that propose new system attributes are responsible >> for all aspects of those attributes. Including the decisions on >> whether or not they are set by a user-level API and whether or not >> they are displayed by ls(1) or any other utility. >> >> This project team cannot predict what future attributes will be >> proposed. >> >> - The Utilities Team may choose to take advantage of the nvpair >> format returned by fgetattr(). This will allow them to format >> and display (name and value) all available system attributes. > > This case should be providing the basic infrastructure to enable > extensible attributes to be used correctly. It seems to me that this > project is incomplete for two reasons: > 1. it doesn't provide a mechanism for extensible attributes to > identify themselves, and See the fgetattr.3c man page in the materials directory. Specifically "Example 1". fgetattr() returns an nvlist_t which is composed of nvpair_t's of all the system attributes supported by this file system. The application can then iterate through each nvpair in the nvlist and use the interfaces in the nvpair library to determine the name, type, and value of the attribute(s). > 2. it doesn't provide a registration mechanism for non-"system" > extensible attributes. > As mentioned above, this case is about extensible system attributes. The project team is not asking for any policy change for extended attributes described in PSARC 1999/209. -Mark
