Hi,
On Fri, Oct 27, 2000 at 02:33:33PM -0700, Hans Reiser wrote:
> > On Thu, Oct 26, 2000 at 09:26:22PM -0700, Hans Reiser wrote:
> > The API here is designed *exclusively* for non-streamlike attributes.
> > If your filesystem can actually implement stream-like attributes, then
> > you can also use the filesystem namespace to access those attributes
> > --- that's great.
>
> Then design a non-streamlike file api, and make being non-streamlike a feature
>orthogonal to
> everything else.
Umm, that is *exactly* what we are trying to do!
> I don't see why being non-streamlike requires that an extra copy be added to
> assemble the data into your struct.
It doesn't. I already explained why I made that decision, and it had
nothing to do with being streamlike or not. I'm willing to listen to
arguments for and against this, but having a single buffer to pass
from user space to kernel is not something I feel strongly about one
way or the other. Having a single buffer for data on the way back
*is* an important API detail, because that lets us transfer a variable
number of variable-length records back to user space at once, just as
getdents() does for directory entries.
> > Huh? ACLs *must* be updated atomically. You have no choice.
> > Anything else is a security hole. It's not optional.
>
> The atomic restriction can be enforced in a component separate.
Sure --- that's an implementation detail which we don't want to
mandate in the API level.
> I mean, ACLs have all sorts of
> restrictions on them, and atomicity is one of a great many of them, so you have to
>have a separate
> component restricting things anyway.
Right --- and the "attribute family" principle means that the
application is selecting which semantics are required for a particular
API call. That means that ATR_POSIXACL may have all sorts of
implications which, say, ATR_USER may not have. ATR_SYSTEM has
additional semantics on a completely orthogonal axis: it makes
attributes which are not accessible to unprivileged users. Whether we
use something like my proposed API or yours, we definitely need the
way for these additional restrictions to be optional, so that if a
user doesn't need the extra semantics, the implementation is not
forced to provide them.
> All we are doing is making it possible for that ACL
> implementation to use a nice toolkit that will also be used by things other than
>ACLs.
Right --- it's an implementation detail whether or not the ACL code
will use the common core, but if we do have a sufficiently expressive
EA mechanism that can specify (protected,atomic) as attribute
requirements, then it is possible to build a common ACL core on top of
that. If the filesystem's EAs don't provide those semantics then it
will have to provide an alternative ACL implementation which does.
We're definitely in vigorous agreement here.
> You could do the following syntax:
>
>
>/process/range/(X,Y)=>/filename/atomic/ACL/1;/process/buffer/(A,B,C)=>/filename/some_non_ACL_attribute;/process/range/(U,V)=>/filename/atomic/ACL/2
>
> but in any event I hope you can see that some syntax is possible to design for it
>that will work
> well.
It's possible, yes, but in keeping with the spirit of making different
design goals orthogonal, I really want to avoid *requiring* this
belts-and-braces-and-the-kitchen-sink-too API for simple ACL setting.
Providing a clean API for accessing large amounts of different data in
bulk is a separate goal --- the sort of parsing required to implement
all of the above syntax efficiently is _way_ overkill for a simple
"set-this-ACL" call.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
