On Fri, 23 Mar 2018 18:43:12 -0700 Andre McCurdy <[email protected]> wrote:
> Since glibc doesn't provide a wrapper for renameat2, making the > syscall via the libc syscall() API is exactly what coreutils (actually > gnulib) should be doing. There would certainly be grounds to complain > if user space code were making a syscall directly, but that's not > what's happening here - the syscall is still being made from within > libc. Ahh, okay, that clears it up some. I thought coreutils was making a direct invocation of a syscall rather than using the generic syscall wrapper. I guess my thought is that if glibc isn't providing a wrapper for a syscall, it's probably best to avoid that syscall unless it's impossible to run without it. And since I *think* someone may have implemented mv(1) in the past without renameat2(), it seems to me that switching it to use a new syscall that libc doesn't have a wrapper for yet is perhaps premature. There's been a lot of issues we've run into that were caused by coreutils or something near it being very excited about switching to a new, and preferably larger and more complicated, API. Usually to do something that was already being done successfully and without problems; for instance, the use of posix ACL xattrs to encode standard permission bits even when no other ACL functionality is in use. I am not positively impressed by this; if what you're doing can be done entirely with a stable interface that hasn't changed in the last decade or two, switching to a newer interface seems sort of counterproductive. I have some concerns about the API for syscall(), and there's a lot of behavior here that's potentially more-undefined-than-usual; for instance, using va_arg to get more arguments than were actually passed. But it may be we don't really have a way around it. -s -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
