Joerg Schilling wrote: > Roland Mainz <[EMAIL PROTECTED]> wrote: > > Did you omit Davod Korn by intention?
No, I just hit reply (and AFAIK removed [email protected]). AST/Glenns/Davids opinions can be found in https://mailman.research.att.com/pipermail/ast-users/2006q2/000928.html , https://mailman.research.att.com/pipermail/ast-users/2006q1/000890.html and other postings in these lists. > > Joerg Schilling wrote: > > > > runat(1) are not usable outside a lab environment. First at all these > > > > extended attribute files need to be made accessible in the normal file > > > > system name space, otherwise it is just wasted time to deal with them. > > > > > > Roland proposed to implement "cd -@ file" in addition to runat(1). > > > > Uhm... NO. That was not my patch. I just found it and did some > > experiements with it (so did David Korn and Glenn Fowler), with the > > results that the patch will not work. It is a nice technology > > demonstrator, however in their current form the XATTR implementation > > makes an integration into a shell very hard, if not even impossible. The > > patch showed a significant breakdown of various shell features and > > requires a complete rework. > > Why should something that also happens with "runat file" cause problems > in a non-broken shell implementation? > > Note that (in case that you never look at XATTR specifics) you get the same > problems with pwd as you get when you are inside a deleted directory. Erm, no. As long the path is cached in the shell's file name cache no problems occur. If I recall it correctly from the SCTP/mkservice work ksh93 seems to work around beyond that point via generation of weired file names such as /dev/inode/, but that isn't pretty anymore at that point. > If you look at the error messages from ksh, you see the same message > from within a "runat" session and from within an unlinked dir. That's incorrect. "runat" starts the shell without having an abolute $PWD, the ksh93 patch simply added file names which were not resolveable within the shell which caused much trouble. > > To get the patch fully functional at least the following modificatons > > needs to be done (for ksh93): > > - All calls to |open()| needs to be intercepted (which is non-trivial as > > much of this code sits in libast and other libraries) > > Why? Because there is no central location in the shell which calls |open()| (which needs to be replaced by |openat()| for XATTR files), The calls are distributed all over libshell, libcmd and libast, making it very hard to keep it under control. > > - All directory operations need to be adjusted, this includes pattern > > matching, filename completion (vi, emacs, gmacs), file name caching etc. > > Why? Because the code expects that each filesystem object has a proper parent object which can be resolved with normal filesystem operatons. Please read the code. > > - All functions and builts which operate relative to $PWD need to be > > made aware that there is the special case PWD=. and that there are > > directories which live outside the normal namespace > > This also applies to a ksh that runs inside a removed dir. See above. > > - Many of the builtin commands such as "mv", "cp" needs to be modified > > to support XATTRs in their operations, others need to be made aware > > about the PWD=. case > > Never try to implement non-trivial commands inside a shell. This is no solution. Jörg... please... you're not in "auto-defend"-mode to protect the XATTR implementation in Solaris, right ? As I said I have nothing against XATTR files and I even proposed a possible solution for the trouble. Please lets discuss that instead of trying to hack each single application to fit the parallel XATTR file object universe. > Why does ksh miss a "tar" builtin? Umpf... his could be done, however the builtins should be limited to often used utilities to boost performance. /usr/bin/tar is IMO far away from that category. > > - All consumers of libshell need to be adjusted, this includes biosh, > > dtksh, ksh93, tksh and others. > > I don't understand this. It means: You have to apply the same mess with catching |open()|, directory operations etc. to the libshell consumers as they implement lots of builtin commands, too. Please try to understand how ksh93+libshell works, e.g. it could be described as "... a hightly flexible framework to implement shell support for applications...". > > Glenn Fowler suggested (see > > https://mailman.research.att.com/pipermail/ast-users/2006q2/000928.html) > > to solve the problem in the file name resolver in the kernel instead of > > running around madly and trying to make each single application > > "XATTR"-aware (which is - in the case of the POSIX, bourne and ksh > > shells - close to impossible). > > > > What about creating a new system call (and a property which is inherited > > to all the process children) which tells the kernel to access XATTR > > files like the following way: > > % cd file # will become a valid operation (like in Reiser4) > > and > > % cd ... # moves into the XATTR subdirectory > > Maybe the system call should be seperated for directories and files and > > allow the usage of prefix or postfix strings to identify XATTR files. > > This proposal - using ... - (from Microsoft in 2001) has been rejected by the > POSIX commitee because it is not compatible with POSIX. Yes, and the XATTR API seems to be incompatible to the POSIX shell. Wonderfull... ;-( But: Did you actually read my proposal ? I suggested adding a new system call which modifies the behaviour of the file name resolver. Calling it is optional and a way is provided to allow the usage of alternative names, prefixes and postfixes. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-discuss mailing list [email protected]
