Hi,
On Thu, Oct 26, 2000 at 07:50:12AM -0500, [EMAIL PROTECTED] wrote:
> >
> > Our proposed kernel API looks something like this:
> >
> > sys_setattr (char *filename, int attrib_family, int op,
> > struct attrib *old_attribs, int *old_lenp,
> > struct attrib *new_attribs, int new_len);
>
> Does this need the ability to not follow symlinks, or does user
> space gets to do an lstat and a readlink call to ensure we do not
> follow links, or do depending on the intent - otherwise you cannot
> set an attribute on a symlink.
The standard Unix Way is for all such calls to follow symlinks, and to
have a separate "sys_lsetattr" which doesn't if we really want to be
able to set such properties on symlinks. How important is attributes
on symlinks?
> > where <op> can be
> >
> > ATR_SET overwrite existing attribute
> > ATR_GET read existing attribute
> > ATR_GETALL read entire ordered attribute list (ignores new val)
> > ATR_PREPEND add new attribute to start of ordered list
> > ATR_APPEND add new attribute to end of ordered list
> > ATR_REPLACE replace entire ordered attribute list
>
> Does any filesystem implement an ordered list?
For ACLs, yes. For named attributes, a few do, most don't.
> How do you atomically create an attribute, i.e. you want to set the
> attribute to a value if it does not already exist
Is there a need for that which can't be dealt with by doing a
set-and-get?
> > and where <attribs> is a buffer of length <len> bytes of variable
> > length struct attrib records:
> >
> > struct attrib {
> > int rec_len; /* Length of the whole record:
> > should be padded to long
> > alignment */
> > int name_family; /* Which namespace is the name in? */
> > int name_len;
> > int val_len;
> > char name[variable]; /* byte-aligned */
> > char val[variable]; /* byte-aligned */
> > };
>
> If the typical operation is manipulating a single attribute then
> encoding the attributes into a single byte array like this will
> tend to mean that the user program gets to do a couple of memory copies
Yes, but there is also a need to be able to read arbitrary attributes
from the kernel (eg. read all ACLs, or read all user attributes for a
"cp" operation). The GETALL operation obviously has to be able to
return an unknown number of value buffers in that case, so we can't
fake this by letting the application post separate read buffers ---
stuffing the attributes into a single read buffer is by far the
cleanest approach for GETALL.
The only reason I then adopted that single-buffer for write was to
keep the data structures consistent between set and get operations.
I'm not opposed to changing that, as long as you realise that having
out-of-line buffers for set makes the API quite assymetric in this
respect.
> > ATR_SET will overwrite an existing attribute, or if the attribute does
> > not already exist, will append the new attribute (ie. it does not
> > override existing ACL controls, in keeping with the Principle of Least
> > Surprise). If multiple instances of the name already exist, then the
> > first one is replaced and subsequent ones deleted. If supplied with
> > an "old" buffer, all old attributes of that name will be returned.
>
> Again, are there filesystems which support multiple instances of
> the same attribute?
Yes --- in particular you can set multiple ACEs keyed on the same name
(eg. an access control ACE plus an audit ACE).
> For an existing API (which I am not proposing be taken as is) take a look
> at the xfs man pages here:
>
> http://oss.sgi.com/projects/xfs/manpages.html
>
> All the attribute calls are conveniently at the top of the list.
Thanks.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
