Hans Reiser wrote:
> Curtis Anderson wrote:
> > Hans Reiser wrote:
> > > We should
> > > just decompose carefully what functionality is provided by attributes that
> > > files and directories lack, and one feature at a time add that capability
> > > to files and directories as separate optional features.
> >
> > It all depends on how optional things are, and what differences an unmodified
> > app sees. IMHO, "none" is the right answer in this case. Part of my believing
> > that directory-hack stream-style attributes are not good is that I don't know
> > how to do them without making visible changes in the semantics of existing
> > objects. Proposing examples on how to make these extensions transparently to
> > existing apps would help.
>
> So really your logic supports not having a common extended attribute API
> but having each fs do it its own way. This is okay with me.
No, I believe that we should have a common API. Each filesystem should be
able to implement the storage/retrieval of EAs however it wants to, but
portability of applications demands that the semantics of the API be fixed
across filesystems.
I like Stephen's API in that it gives us a clean way of specifying the
semantics that we expect out of the API call (via the name family). Given
a defined name family, the filesystem must either fulfill on the semantics
that the name implies, or it must reject the request.
Thanks,
Curtis
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
