[OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

[Andre McCurdy]

On Wed, Apr 4, 2018 at 2:28 PM, Khem Raj <raj.khem at gmail.com> wrote:
> On 3/27/18 8:48 AM, Ross Burton wrote:
>> coreutils is now using renameat2() in mv(1) but as this syscall isn't in most
>> glibc headers yet it falls back to directly calling syscall(), which pseudo
>> doesn't intercept.  This results in permission problems as files mysteriously
>> move without pseudo knowing.
>>
>> This patch intercepts syscall() and returns ENOTSUP if renameat2() is being
>> called.  Thanks to Andre McCurdy for the proof-of-concept that this patch is
>> based on.
>
> what is the performance impact of adding another stack frame and
> function call in the chain here. Do we have data ?

I'm not sure if anyone has done any formal measurements, but the
overhead of wrapping libc APIs is certainly noticeable in some cases.
For example running "git status" in a devshell under pseudo is
noticeably slower than from a regular shell. e.g.

Within a devshell for glibc:

  # time git status
  real    0m1.552s
  user    0m0.235s
  sys    0m0.870s

>From a regular shell in the glibc workdir:

  $ time git status
  real    0m0.067s
  user    0m0.034s
  sys    0m0.033s

Of course most the overhead here comes from what pseudo does inside
the wrapper, not from the wrapper itself. For tasks which are CPU
bound (e.g. compiling) and calling into the libc functions which
pseudo wraps less often than "git status" does, the overhead will be
much less.