> Combined with the fact that, as mentioned, errno numeric values are not > portable across architectures, I think it's better to just prohibit them > outright rather than allow users to write jobs that will behave in > unexpected manners.
I wouldn't advice using numeric values either, I'd only allow them as fall-back. James' concern seems to be that syscall numbers might be missing, and that might be just as much the case for errno numbers... If someone likes to use a numeric value he *must* have a very good reason for doing so and he should realize that that's risky/non-portable/hackish. Again, Systemd does not support an errno policy at all, no-one else is supporting an errno-string, Chromium . However, I almost forget that the original motivation was to combine the syntax for both the errno and trap policy. Trap sets "si_errno" but it does not seem to be used like errno (but to communicate a "reason" for trapping this particular syscall). Errno strings like "EACCES" might make sense for trap, but other (numeric) values also make sense. >> I did look at arch/x86/syscalls/syscall_*.tbl and >> include/asm-generic/unistd.h and arch/x86/include/asm/seccomp*.h >> Anyway, just like with errno we could also allow a numeric value as >> fall-back for future syscalls, I hope that addresses your concerns? > > syscall numbers are even less portable than errno. True, but I'm trying to address James' concerns. It'd be only a fall-back. Again, if someone likes to use a numeric value he *must* have a very good reason for doing so and he should realize that that's risky. (I just noticed that on Ubuntu 12.04 LTS the x32 syscall-numbers are also missing.) Kind regards, David G -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
