On 29 August 2012 10:01, Roland Mainz <roland.ma...@nrubsig.org> wrote:
> [Forwarding email since somehow the ast-developers@ list has issues
> with postings from Olga's address... ;-( ]
> ---------- Forwarded message ----------
> From: ольга крыжановская <olga.kryzhanov...@gmail.com>
> Date: Wed, Aug 29, 2012 at 7:36 AM
> Subject: Fwd: Per thread open(), stat(), rename() and so on, and *at() API
> To: Roland Mainz <roland.ma...@nrubsig.org>
>
>
> Wenn du wach bist schick es bitte nochmal an
> ast-developers@research.att.com. Meine mail ist im spam-filter
> hangengeblieben.
> ---------- Forwarded message ----------
> From: ольга крыжановская <olga.kryzhanov...@gmail.com>
> Date: Wed, Aug 29, 2012 at 6:54 AM
> Subject: Per thread open(), stat(), rename() and so on, and *at() API
> To: Glenn Fowler <g...@research.att.com>, David Korn
> <d...@research.att.com>, Phong Vo <k...@research.att.com>
> Cc: ast-developers@research.att.com
>
>
> Glenn, I have an alternative for your per thread open(), stat(),
> rename() and so on API plans:
>
> Instead of creating AST wrapper code for open(), stat(), rename() and
> so we could use the following macros, defined in <ast/fcntl.h>:
>
> ------------------cutme------------------------
> #define unlink(path)
> unlinkat(AST_GET_CURRENT_THREAD_CWD_FD(), (path), 0)
> #define rmdir(path)
> unlinkat(AST_GET_CURRENT_THREAD_CWD_FD(),
> (path), AT_REMOVEDIR)
> #define chown(path, uid,
> gid)            fchownat(AST_GET_CURRENT_THREAD_CWD_FD(), (path), (uid), 
> (gid),
> 0)
> #define lchown(path, uid, gid)
>         fchownat(AST_GET_CURRENT_THREAD_CWD_FD(), (path), (uid), (gid),
> AT_SYMLINK_NOFOLLOW)
> #define stat(path, sb)                  
> fstatat(AST_GET_CURRENT_THREAD_CWD_FD(),
> (path), (sb), 0)
> #define lstat(path, sb)                 
> fstatat(AST_GET_CURRENT_THREAD_CWD_FD(),
> (path), (sb), AT_SYMLINK_NOFOLLOW)
> #define rename(oldname,
> newname)        renameat(AST_GET_CURRENT_THREAD_CWD_FD(), (oldname),
> AST_GET_CURRENT_THREAD_CWD_FD(), (newname))
> #define access(path,
> amode)          faccessat(AST_GET_CURRENT_THREAD_CWD_FD(), (path), (amode), 0)
> #define eaccess(path,
> amode)          faccessat(AST_GET_CURRENT_THREAD_CWD_FD(), (path), (amode),
> AT_EACCESS)
> #define mkdir(path, amode)              
> mkdirat(AST_GET_CURRENT_THREAD_CWD_FD(),
> (path), (amode))
> #define mkfifo(path, amode)
> mkfifoat(AST_GET_CURRENT_THREAD_CWD_FD(),
> (path), (amode))
> #define mknod(path, amode,
> adev)   mknodat(AST_GET_CURRENT_THREAD_CWD_FD(), (path), (amode),
> (adev))
> #define readlink(path, buf,
> bufsize)        readlinkat(AST_GET_CURRENT_THREAD_CWD_FD(), (path), (buf),
> (bufsize))
> #define symlink(oldpath, newpath)       symlinkat((oldpath),
> AST_GET_CURRENT_THREAD_CWD_FD(), (newpath))
> ------------------cutme------------------------
>
> AST_GET_CURRENT_THREAD_CWD_FD() would be defined to be a preprocessor
> macro, which will be a function returning the current thread's cwd fd;
> if there is none allocated for this thread yet it will be done by
> within that function, using open(".", O_search).
>
> However, consumers of the <ast/fcntl.h> header are _free_ to redefine
> this macro, for example src/cmd/ksh93/include/defs.h could define
> AST_GET_CURRENT_THREAD_CWD_FD() as
> #define AST_GET_CURRENT_THREAD_CWD_FD() (shp->pwdfd)
> This would, at least, save the function call overhead, and finally
> make use of (shp->pwdfd) as it was intended.
>
> What do you think? It would make things easier for you to implement,
> i.e. you only have to implement the per thread
> AST_GET_CURRENT_THREAD_CWD_FD(), and applications are free to use the
> *at() API if they wish to.

What is the purpose of the change? Wouldn't it be easier to just to
make a sweep of the codebase using an awk script and replace the
functions with the new functions, instead of adding yet another
#define for standard filesystem calls? I think the current number of
cpp redirects for such calls has reached a number of nesting levels
which has become unsustainable.

Lionel

_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers

Reply via email to