Hi,
On Sat, Oct 28, 2000 at 02:09:17AM -0700, Hans Reiser wrote:
> "Stephen C. Tweedie" wrote:
> >
> > 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.
Pardon? This has nothing to do with atomicity. This is just about
data format: how you pass an unknown number of objects from the kernel
to user space. Atomicity has absolutely nothing to do with this.
> > 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?
Yes, but why can't you see that we are not trying to solve ALL of your
problems at once here? We are not inventing an API for some
theoretical future FS here. We are trying our best to deal sanely
with a bunch of existing filesystems whose semantics we *CANNOT*
choose, because we already have disks encoded in the existing layouts
and with the existing semantics.
> > 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.
ACLs cannot be delegated to apps --- they are security features which
must be enforced rigidly by the kernel.
If you want extra functionality and generality for applications, then
that's great, and I'll be glad if you succeed, but it is a different
problem.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
