[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ast-users
Subject:    [ksh93-integration-discuss] Re: XATTR support in ksh93 ? / was:
From:       gsf () research ! att ! com (Glenn Fowler)
Date:       2006-05-15 13:02:44
Message-ID: 200605151702.NAA70495 () raptor ! research ! att ! com
[Download RAW message or body]


On Mon, 15 May 2006 18:43:39 +0200 Joerg Schilling wrote:
> Roland Mainz <roland.mainz@nrubsig.org> wrote:

> > The XATTR files need to be accessible from the normal filesystem
> > namespace (e.g. each file needs a proper parent (even if this is a file,
> > but that does not hurt as seen in Reiser4 :-) )), otherwise the shell
> > can only access them via weired helper applications.

> I strongly object this idea.

> XATTRs do not belong in the same namespace as filenames and what Reiser4 does
> is just a result of the limited Linux development model. Note that you may 
> _add_ anything to Linux but you will not be able to force all other
> programmers to modify their code in order to allow a better and more orthogonal
> behavior. For this reason, every implementor tries to find a way to implement all
> features in his own project. This development model sucks....

so Jörg
I'm confused with your response

the whole point of adding extensions like XATTR to the filename space is that it
would force reprogramming only inside the system call implementations -- no user
level reprogramming would be required

the alternative of adding parallel universe system calls for each XATTR-like
extension would force every user level application to reprogram to each
XATTR-like extension, ultimately ending up with, at minimum,
#syscalls * #extensions calls, and that doesn't address the issue of interactions
between extensions

what reprogramming does "force all other programmers to modify their code" refer to
w.r.t. putting extensions in the filename space?

(I'll condede that under either method backup/copy utilities might want to provide
 options to control how extensions are to be handled)

-- Glenn Fowler -- AT&T Research, Florham Park NJ --

[prev in list] [next in list] [prev in thread] [next in thread]