Hi,
On Tue, Oct 24, 2000 at 03:24:03PM +0200, Christoph Hellwig wrote:
> > I don't understand. This is exactly why I specified that there be an
> > ATR_POSIXACL attribute family. That family *is* a high level
> > interface to ACLs. The whole point of the API was to avoid having to
> > use the low-level attribute functions when dealing with complex
> > objects like ACLs!
>
> Yeah. But I think it is not clearly enuogh separated.
> I think we should have one set of plain name/value syscalls and one
> set of acl syscalls,
Trouble is, even if you separate them, you _still_ need this level of
functionality in the APIs. You may have a separate ACL syscall, but
you still need the ability to have variants, because different
existing filesystems implement different ACL semantics.
You may have a separate EA syscall, but you still have filesystems
which have one unified EA namespace and filesystems which distinguish
between user and system namespaces; filesystems which have separate
named streams and filesystems for which all attributes are streams;
etc.
If you take this to its logical conclusion, _every_ filesystem needs
its own syscalls for ACLs and EA. At some point we HAVE to unify the
APIs.
> because ACLs have nothing in common with EAs
> besides that ACLs can be implemented using EAs as backing store.
Internal implementation detail really shouldn't affect the discussion
about APIs. Quotas can be implemented internally using the normal
write() methods of a filesystem, or can be enforced in a completely
different way eg. by having quotas on a remote NFS server. That
is, and should remain, invisible to the write() API.
> > The whole point of the proposal was to allow us to have the extended
> > attribute and the ACL functionality clearly separated, but still
> > presented in a uniform API.
>
> And I think that ACL and EA should be separated because they are
> completly different things.
TCP and unix domain sockets are completely different things. They
have *totally* different namespaces --- quad-octet binary vs.
pathnames. Yet they still deal with "write this block of data to that
remote name" through the same socket/connect/write/close API.
The attribute family gives you the separation of these different
things in a flexible, and --- more importantly --- extensible manner.
You can add new protocols like DECNET or SNA to the BSD socket API
without adding new syscalls. You should be able to do the same in an
attribute API, so that adding support for (say) HPFS ACLs or NTFS
extended attributes doesn't require revving the syscalls.
> > The ACL API *has* to be done in some form
> > of extensible way anyway,
>
> Yeah. I think your family-like API doesn't belong in the EA layer but in
> the high-level ACL layer. This ACL layer would have it's own syscalls,
> e.g. (very similar to you EA API):
> The EA API would be the one proposed by Andreas:
>
> sys_eattr (char * filename, int cmd,
> const char * name, char * value,
> size_t size);
But that API is insufficient for EAs. We already have filesystems
which implement independent system and user namespaces: adopting a
random new convention like "system attributes start with '$'" is
incompatible with those, so we can't ever mount an existing XFS (for
example) filesystem and access its EAs cleanly.
It's the existence of these existing, mutually (and sometimes subtly)
incompatible semantics for EAs which was behind the proposal of doing
attribute-family versioning for EAs as well as for ACLs.
> Yes it does. But I don't like mixin the low-level and high-level API
> in the same syscall.
They are NOT low- and high-level. That's an artificial distinction.
On some filesystems (such as distributed filesystems), they might be
*exactly* the same level as far as the local client is concerned, with
all the other semantics being done on the remote server.
To give you a concrete example, the VMS filesystem has ACLs as the
low-level API, and EAs as high level ones --- on VMS, extended
attributes are actually implemented as "Application ACL entries",
completely turning upside-down your argument that ACLs are built on
top of EAs!
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
