[Resending this via Russell's list, due to oss.sgi.com<->melbourne
mail handling issues at the moment.]
----- Forwarded message from Nathan Scott <nathans@xxxxxxx> -----
Date: Tue, 16 Apr 2002 10:28:12 +1000
To: Greg Freemyer <freemyer@xxxxxxxxxxxxxxxxx>
Cc: Eric Sandeen <sandeen@xxxxxxx>,
Simon Matter <simon.matter@xxxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
User-Agent: Mutt/1.2.5i
From: Nathan Scott <nathans@xxxxxxx>
Subject: Re: re[4]: XFS installer and driver/update disks
On Mon, Apr 15, 2002 at 02:41:14PM -0400, Greg Freemyer wrote:
> Eric / Nathan,
>
> I guess I'm just totally confused, and I thought I was following this subject
> fairly closely.
OK, here's some answers. I'll try to stick to the facts... I really
don't want to get involved in the politics here.
> I understood the below to be true (but apparently I'm wrong):
>
> ======
> The 2.5 kernel had syscalls added to it to support EAs in general.
Yup. In addition, a VFS interface was also added (ie. there are
multiple definitions of "interface" in this discussion, so beware).
> These syscalls were back ported to the 2.4 kernel and released as a standard
> part of 2.4.18.
The second part of this statement is incorrect - it has an "off-by-two"
error. Marcelo has agreed to include the complete EA patch (that is in
2.5 already, since 2.5.3) in 2.4.20-preX.
In 2.4.18 Marcelo took a patch to mark the extended attributes system
calls as reserved, and it was 2.4.18 that we switched the XFS CVS tree
over to the new interfaces.
> These new EA syscalls are being used by the user tools to implement ACLs.
>
> Shortly after the release of 2.4.18, a new set of XFS kernel patches were
> released that allowed the new syscalls to be compatible with XFS. This did
> not impact on the on-disk format. The xfs acl user tools for manipulating
> ACLs became broken at this point. i.e. the old kernel entry points that the
> xfs acl user tools depended on were no longer provided by the XFS patches.
Yes, this is correct.
> The acl.bestbits user tools were upgraded to support these new syscalls.
> Therefore these tools work with XFS on a 2.4.18 kernel.
Yep.
> Due to the fact that XFS and acl.bestbits now share a common kernel API for
> ACL support, the previous xfs-user tools for manipulating ACLs have been
> retired, and the upgraded acl.bestbit tools are now used instead.
Yes, this is now a shared project - both groups are involved in
the ongoing development of acl/attr packages in a cooperative
manor. eg. the ACL web site is still a much better source of
ACL-specific info and those folks host the web site, the mailing
list, etc. They asked if we would continue to maintain the CVS
tree for the user tools, and we do; plus many changes have been
made to both of our patch sets to make them work better together.
> The libacl.so library from acl.bestbits has also been upgraded to use the new
> syscalls.
>
> Therefore, programs like Samba 2.2.3a that use the libacl.so package to
> access ACLs automatically support the new syscalls by simply upgrading the
> libacl.so library to a current version.
Yes, Samba uses the libacl API and has no knowledge of system calls
or even ACL data structures (which are intentionally hidden below the
libacl API, and an opaque acl handle is passed around above the API).
This libacl implements the (withdrawn draft) POSIX 1003.1e ACL
interfaces which several UNIX variants also implement.
> ====
> If someone could please clarify the above, I would appreciate it.
>
> In particular statements that the 2.4.18 kernel does not have ACL support yet
> seems totally contradictory to the above.
It would technically be true to say no official kernel has any ACL
support yet. Such a statement is deliberately misleading, however,
and the changes needed to add ACL support to the kernel above and
beyond what is already there are trivial.
For Christoph:
One approach that you and the IBM guys might want to investigate
is to implement the code behind the xattr VFS interfaces (and only
conditionally compile that file), and then tell people to get the
bestbits patches to enable that EA/ACL support (this would allow you
guys to get the the 2.4 JFS support in there too, without needing to
make any changes to the kernel outside of JFS, which seems to be the
JFS mantra). Just a thought, maybe it helps maybe not, I dunno.
The VFS locking changes we have in 2.5 are at the request of the
ext2/ext3 camp, and have been sent on to Linus (this is part of the
wider VFS BKL changes in 2.5, so is inappropriate for 2.4).
For the guys following that Redhat bug:
I guess one could also point out that its hypocritical to claim that
these EA/ACL interfaces can't be used because the ABI _might_ change
(which is extremely unlikely - neither the XFS nor the ext2/3 projects
have any plans to change the EA format for ACLs; the format also has a
version field which can be used to support backward compatibility _if_
that should ever become necessary; and userspace uses the libacl API
which hides this anyway!), while most of the distributors, including
Redhat, use a quotactl(2) interface with an ABI which _does_ differ to
that in the standard kernels from Linus/Marcelo.
cheers.
--
Nathan
----- End forwarded message -----
--
Nathan
|