ACL problem with NFSv4 and DELETE_ACCESS

[Jiri Sasek - RPE Prague]

Nicolas Dorfsman wrote:
>
>     Hi Volker,
>
> Le 18 juin 08 à 11:52, Volker Lendecke a écrit :
>>
>> Just found in the SUN docs of the acl(2) system call that is
>> evolving or uncommitted. This is really brillant, because
>> according to their docs it means:
>>
>>> No commitment is made about either source or binary
>>> compatibility of these interfaces from one Minor release to
>>> the next. Even the drastic incompatible change of removal of
>>> the interface in a Minor release is possible.
>>
>> Can we use this AT ALL?
>
> man -s5 attributes extract :
>
>      Evolving
>
>          An Evolving interface may eventually become Standard  or
>          Stable but is still in transition.
>
>          Sun will make reasonable efforts to ensure compatibility
>          with  previous  releases as it evolves. When non-upwards
>          compatible changes become necessary, they will occur  in
>          minor  and  major releases; such changes will be avoided
>          in micro releases whenever possible. If such a change is
>          necessary,  it  will  be documented in the release notes
>          for the affected release, and when  feasible,  Sun  will
>          provide migration aids for binary compatibility and con-
>          tinued source development.
>
>
> Are you still afraid ?

"Evolving" really mens the interface is uncommitted and can be changed 
by Sun but  in case of the acl(2) you should have on your mind the ace_t 
structure is using layout of the "NFSv4 wire format" for the flags so 
the RFC 3530 should be rewritten first in this case. Also the ZFS is 
using the NFSv4 extended ACL interface so here is a lot of code in 
Solaris which should be rewritten in such case  :-)

Jiri