Hi,
On Wed, Oct 25, 2000 at 09:09:57AM -0700, Hans Reiser wrote:
> Why do you force the user to copy the data into the attrib structure, rather than
>letting him leave
> the data where it lies and simply specify the location to the kernel?
In the first draft of the API put together, I did in fact leave the
attributes intact and just referred to the buffers indirectly.
However, that breaks for GETALL, where the application is giving the
kernel a large buffer into which an unknown number of attributes may
be written. It also breaks the old-value return from the SET
functions if, for example, you are setting an ACL on a uid which
already has more than one ACL entry.
Basically, for returning an unknown number of items to user space,
it's much cleaner just to let the kernel stuff all of the data into a
single return buffer.
We _could_ specify different data layouts for set and get, but that's
ugly.
> Why do you treat attributes differently from files? Why is your interface specific
>to attributes
> rather than files generally with attributes being files with a particular name?
Atomic updates.
There are existing filesystems which have completely separate
namespaces for block-attributes and for named streams. Named streams
have proper file semantics, but block attributes do not --- they have
a fixed maximum size and are read/written in one single go.
Furthermore, for security applications (eg. ACLs) you really want the
atomic update guarantees to be 100% failsafe in the kernel, and
ideally you want atomic get-and-set.
The extended attribute API was meant for situations where we are
dealinng with these sorts of attributes, not for places where streams
are more appropriate.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
