"Stephen C. Tweedie" wrote:
>
> 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.
That is why I use a sequence of assignment statements in my proposal for a syntax.
That allows you
to leave in place the data, and assign multiple file contents to multiple locations in
the process
address space, or use a file descriptor to access the contents, as the user chooses.
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.
Do you see why I disagree on this?
>
> 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.
You are saying we need a transaction syntax with a transaction start and a transaction
end operator
pair, yes? Let's stop being inferior to databases..... this is something new, let's
do it right.
>
> 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.
So you need an EINCOMPLETE_IO or some such, yes? procfs has the same problem, let's
solve it
orthogonally to this discussion.
>
> 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.
You can access as a stream or as an atomic unit, just specify it or constrain it, but
that should be
an orthogonal feature.
>
> Cheers,
> Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
