one example of intercepting/renaming syscalls is <ast.h> already, and for a while, translates all foo() syscalls to foo64() where foo64() is avaliable
On Wed, 29 Aug 2012 09:10:34 -0400 Glenn Fowler wrote: > we're going to take some research leeway and investigate the implications of > {a} > we're not strangers to doing stuff like that (3d(1)) > and we're not strangers to having research prove us wrong > On Wed, 29 Aug 2012 14:49:33 +0200 Cedric Blancher wrote: > > On 29 August 2012 13:54, Roland Mainz <roland.ma...@nrubsig.org> wrote: > > > [Forwarding since AT&T's spam filter is on drugs... ;-(( ] > > > ---------- Forwarded message ---------- > > > From: ÏÌØÇÁ ËÒÙÖÁÎÏ×ÓËÁÑ <olga.kryzhanov...@gmail.com> > > > Date: Wed, Aug 29, 2012 at 1:20 PM > > > Subject: Re: [ast-developers] Fwd: Per thread open(), stat(), rename() > > > and so on, and *at() API > > > To: Lionel Cons <lionelcons1...@googlemail.com> > > > Cc: Roland Mainz <roland.ma...@nrubsig.org>, > > > ast-developers@research.att.com > > > > > > > > > Lionel, there are 2 purposes: > > > > > > 1. Allow that ksh93/libshell can be embedded in other applications > > > (Roland calls this 'back end usage', i.e. the user is not aware that > > > he is interacting with a shell, and neither do any other apis know > > > that, or at least should not have to know about that), with out > > > interfering the calling application by changing the current working > > > directory. > > > 2. Allow that ksh93/libshell and the libast api can have a per thread > > > current working directory. > > > > > > There are 2 proposals how to accomplish that: > > > a) Add wrapper functions for open(), stat(), lstat(), chdir(), > > > fchdir(), access(), eaccess(), rename() and so on, and redirect them > > > to their *at() counterparts, with dirfd set to the current threads cwd > > > fd. > > > > > > or > > > > > > b) Add wrapper cpp macros which redirect open(), stat(), lstat(), > > > chdir(), fchdir(), access(), eaccess(), rename() and so on to their > > > *at() counterparts, but define an extra macro which is AT_FDCWD for > > > non threaded applications, and calls a function to obtain the current > > > threads working directory fd for the current thread, but allows to > > > override this macro on a per source file basis, so that applications > > > like libshell, who maintain their own cwd directory fd, can use that. > > > > > > David and Glenn seems to prefer {a}, while I and Roland prefer {b}, > > > because {b} will allow an application to work as back end api without > > > interfering with the global cwd or any other, may be libast based apis > > > cwd. This includes nested usage of libshell, like for system() or > > > wordexp(). > > I'd prefer option {b}, too. Strongly (sorry David and Glenn :)). > > It sounds like the more sane and flexible way to do this. The big road > > block is that you have to find a solution for old platforms which do > > not have openat() and friends, or EOS (end-of-support) them (I'd > > support that if no platform younger than four years lacks openat() and > > friends). > > Ced > > -- > > Cedric Blancher <cedric.blanc...@googlemail.com> > > Institute Pasteur > > _______________________________________________ > > ast-developers mailing list > > ast-developers@research.att.com > > https://mailman.research.att.com/mailman/listinfo/ast-developers > _______________________________________________ > ast-developers mailing list > ast-developers@research.att.com > https://mailman.research.att.com/mailman/listinfo/ast-developers _______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers