Author: Federico Sevilla III <jijo@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 2 Feb 2002 11:52:38 +0800 (PHT)
So setups utilizing ACLs won't have to be redone, right? As long as we make sure that when we upgrade to an XFS-enabled kernel using the new system calls we also upgrade the userland stuff or we won'
for XFS at least yes. on disk format is unchanged, only the syscalls are different. however it looks like only the extended attributes syscalls have been added to 2.5, there is still no ACL interface
We will be moving to the acl.bestbits.at implementation of ACLs which uses the extended attributes interfaces directly for ACLs, rather than separate syscalls as we have currently in the XFS tree. So
ah i see, so there will be no acl syscalls in the kernel, all of that will be handled entirly in the userspace libacl, which uses the xattr API just added yes? does that mean libacl will need to know
hmm, but as im understanding this libacl will just be writing an extended attribute to a file, how will XFS, or whatever know this attribute is for ACLs rather then just some arbitrary attribute? the
attributes in the system namespace will need to be converted to the native filesystem format before/after being written/read. yes, we'll need to improve some areas of the documentation - several peop
yes, i was wondering where this conversion happens, libacl, or the kernel. -- Ethan Benson http://www.alaska.net/~erbenson/ Attachment: pgp4r0nSpiITp.pgp Description: PGP signature