On Fri, 23 Mar 2018 23:47:30 +0000 Richard Purdie <richard.pur...@linuxfoundation.org> wrote:
> On Fri, 2018-03-23 at 11:49 -0500, Seebs wrote: > > On Fri, 23 Mar 2018 16:30:55 +0000 > > "Burton, Ross" <ross.bur...@intel.com> wrote: > > > > > > > > Because in GNU's infinite wisdom they're using renameat2() to do > > > atomic renames in the mv command, and as renameat2 isn't in the > > > headers for F27 it just does a syscall directly. This is in > > > upstream > > > coreutils so once they make a release, everyone gets it. > > UGH. > > > > I... am really unsure whether it's possible to catch that, because > > I really, really, don't want to try to intercept raw syscall() > > calls. I don't think that ends well. > > Just out of interest for my education, why is that a really bad idea? > Loops, e.g. with memory allocation issues? Potentially. We rely pretty heavily on the assumption that an *actual* syscall can go through. Although... Actually, I don't even know if this is an actual syscall. This could be an actual glibc wrapper around the syscall interface, just like all the others, which is not the *actual* raw syscall or whatever, and... I have no idea how often that is or isn't hit. It's totally possible it would work, but basically, I have a pretty good intuition of when something sounds brittle and error-prone, and trying to trap syscall() sounds brittle and error-prone and might work today but not next week... -s -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core