> Hi again,
>
>
> There were some good arguments for adding a few more features to the EA
> interface. This new proposal reflects some of the discussion.
>
> I still decline to support forks/streams through the EA interface. IMHO
> that's just the wrong way to go. This doesn't preclude an EA
> implementation on top of streams, of course.
>
> The interface described here also doesn't include Stephen's idea to allow
> an ordered list of EA's under the same name. In addition to the append and
> prepend operations Stephen suggested, a whole range of other operations
> (get/delete/... by index, etc.) might make sense, and stuff like that
> could well be added. However, it would complicate the semantics even
> further. I'd really like to learn more about the requirements for that.
>
You previously asked if there were any concerns about the proposed
interface from the XFS team. This new proposal seems to fix almost
everything, except we would like to be greedy and ask for more than
32 bits to represent a location in the attribute list for the
EA_REQ_LIST call. Attributes in xfs are not stored in a manner
which makes them have an offset, in irix we use a cursor structure
which is 4 32 bit numbers long. Actually, without doing some digging
into the code I cannot tell exactly what we would need for this.
If the EA_REQ_LIST was implemented above the vfs layer by making
a sequence of calls for individula attributes down into the filesystem
then I suspect we would have real difficulties with it, if it was
implemented within each vfs, or at least allowed to be in the vfs
then this would probably be doable.
Also, it is not totally clear how the list call would return attribute
data, or would it just return names and get calls would be required
to read the values?
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
