"Stephen C. Tweedie" wrote:
>
> 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!
Does your API allow me to access a non-stream file, and not just a non-stream
attribute? Why isn't
it called the non-stream API?
>
> > 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.
Now I am really confused. I understood why you wanted an atomic write, but you say no
you don't,
you want an atomic read. Why in the world does an atomic read require that everything
be in one
block. There are tons of ways to implement an atomic read, the most obvious being a
user library
that makes the process wait for the syscall to return successfully.
>
> > > 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.
Ok, so if you generalize your attribute family concept to files instead of just
attributes you get
my plugin concept, yes? Do you see why I want the more general abstraction?
In the plugin model every object in the FS has a plugin-id, and that plugin-id
identifies the plugin
that manages all access to it (implements the VFS operations, plus who knows what
else.)
>
> > 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.
You are responding to a specific application need (ACLs) by giving the app exactly the
features it
needs all tied together in the way the app needs it rather than decomposing each thing
into an
orthogonal feature that can be combined in that way by the app if it chooses to do so
but can also
be combined differently by other apps if they choose to. This is how general purpose
architectures
acquire cruft over time.
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
