On Sun, 29 Oct 2000 [EMAIL PROTECTED] wrote:
> 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.
That seems to make sense. I was actually also thinking of using some sort
of cookie for that when I wrote that up.
Is the cursor robust enough to be exposed to userspace, or is there a
potential for compromising it (the bounds of an offset can easily be
checked so that wouldn't be a big problem)?
> 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.
All the operations should probably be implemented at the FS level.
> 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?
I was actually thinking of using LIST, followed by GETSIZE and GET for the
most general case.
Andreas
------------------------------------------------------------------------
Andreas Gruenbacher, [EMAIL PROTECTED]
Contact information: http://www.bestbits.at/~ag/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
