Mark Shellenbaum wrote: > Joe Blount wrote: >> >>>> Is the acl_t intentionally designed to be opaque? >>>> >>> >>> Yes, its meant to be opaque. >>> >>> The layout of the acl_t will likely change in the not too distant >>> future. >>> >> >> Will old versions be supported? For example, if ADM >> <http://www.opensolaris.org/os/project/adm/> treats it as opaque and >> archives the current format, after an upgrade (layout change), could >> we write the old ACL to the new ZFS code? >> >> thanks, >> Joe > > acl_t is a purely in-core data structure, and is not appropriate for > storing in an archive. Thats what interfaces such as acl_totext() are > for. ADM should be archiving the ACL in a textual representation, > much like tar/cpio do. We're trying to use DMAPI interfaces for all interaction with the filesystem. The DMAPI interfaces take a DMAPI handle (fsid & fid), and call the DMAPI kernel driver which uses the handle to get a vnode and do whatever was requested... I was hoping to add a DMAPI ACL interface like this - in the kernel get the ACL for a vnode (VOP_GETSECATTR), and convert it to text... Is there an acl to text interface available in the kernel?
thanks, Joe > > The interfaces such as acl_get()/acl_set() are merely convenience > functions to make it easier for getting/setting ACLs without having to > know if the file system is ZFS or UFS. For example acl_get() knows > how to determine if a file system supports POSIX draft ACLs or NFSv4 > ACL and then uses the native acl(2) syscall to retrieve the data. > > > -Mark _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
