"Stephen C. Tweedie" wrote:
>
> 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!
If I talk others into using it, then the name changes.....:)
>
> >
> > /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.
If you implement just the features I described there is very little work to parse it.
It is only if
we add more features later....
;-)
>
> > /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!
Do you need reads into user space to be atomic, or do you need writes into kernel
space to be
atomic. I think you only need the writes into kernel space to be atomic, yes? Define
your atomic
needs more precisely if you can.
>
> 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.
Maybe we should just let the filesystem decide which operations on which objects to do
atomically if
they are in the same syscall whether asked or not, which ones not to do atomically at
all even if
asked, and which to do atomically if asked to. Do you agree with that?
>
> 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
I don't yet see that.
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
