xfs
[Top] [All Lists]

Re: [NEWS] Extended attributes interface changes

To: Ethan Benson <erbenson@xxxxxxxxxx>
Subject: Re: [NEWS] Extended attributes interface changes
From: Nathan Scott <nathans@xxxxxxx>
Date: Sun, 3 Feb 2002 20:49:59 +1100
Cc: Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>
In-reply-to: <20020203003105.B14742@plato.local.lan>; from erbenson@alaska.net on Sun, Feb 03, 2002 at 12:31:05AM -0900
References: <20020201101545.G88469@wobbly.melbourne.sgi.com> <Pine.LNX.4.44.0202021151090.5765-100000@gusi.leathercollection.ph> <20020201213849.Y14742@plato.local.lan> <"from <20020203125739.B104828@wobbly.melbourne.sgi.com> <20020203003105.B14742@plato.local.lan>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Sun, Feb 03, 2002 at 12:31:05AM -0900, Ethan Benson wrote:
> On Sun, Feb 03, 2002 at 12:57:39PM +1100, Nathan Scott wrote:
> > 
> > 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, there will be no second change for ACL userspace, it will
> > all be done in one big step.
> 
> 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?

yup.

> 
> does that mean libacl will need to know about the on disk format for
> ACL extended attributes for each filesystem it supports? 
> 

No, we'll convert to/from a common (VFS) format into the XFS-specific
format before writing / after reading the ACL.

cheers.

-- 
Nathan


<Prev in Thread] Current Thread [Next in Thread>