Hi,
On Wed, Oct 25, 2000 at 08:45:28AM -0700, Hans Reiser wrote:
> reiser4_sandbox(char * command, int string_length)
>
> where command has a syntax of:
>
> "lhs<=rhs;lhs<=rhs;lhs<=rhs;..."
If it's called "reiser4_sandbox" then it's hardly a generic API for
attributes and ACLs, which is what we were trying to achieve!
>
> /process/fd/address_to_write_file_descriptor
> or
> /process/buffer/(buffer_start, buffer_end, count_bytes_written)
Sounds like an aweful lot of parsing has to go on in the kernel to
make this work. I'm not convinced that that doesn't outweigh any
syscall overhead of simpler APIs.
> /filename/attribute
>
> to access an attribute in its entirety, depending on what you want to do.
But what about attributes which cannot be decomposed so cleanly into
bytestreams?
Also, your proposed API is _too_ flexible to be useful for atomic
guarantees --- there's just no way you can say "transfer this several
GB of file stream into that buffer there" and expect to have it
atomic!
For distributed filesystems, there may well be no atomic operation on
ACLs at all other than small, well-defined ones. Over-engineer the
interface and you lose all the elegance for no gain, because the
application just can't use the fancy bells and whistles without losing
the atomicity guarantees.
It still feels to me as if the massive bulk IO requirements and the
small, precisely-defined attribute API requirements need two
interfaces here.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
