ping @ben and @vinodkone, would you like to review this patch again? On Wed, Apr 27, 2016 at 7:22 PM, haosdent <[email protected]> wrote:
> Already left my comments on it, thank you for your patch! > > On Wed, Apr 27, 2016 at 5:52 PM, Tomek Janiszewski <[email protected]> > wrote: > >> Hi >> >> I prepared cleanup https://reviews.apache.org/r/46730/ >> @Haosdent can you check it? >> >> Best >> Tomek >> >> śr., 27.04.2016 o 04:03 użytkownik haosdent <[email protected]> napisał: >> >> > Hi, @bmahler, thank you so much for review it! As the email I sent >> > to @idownes and @chenzhiwei, we could drop that safely by adding >> > >> > ``` >> > #include <linux/unistd.h> >> > ``` >> > >> > from @RobinDong's patch. >> > >> > Because this header file comes from kernel headers and it include >> machine >> > specific syscall numbers no matter which CPU architecture used. >> > >> > On the other hand, we can not use >> > >> > ``` >> > #include <unistd.h> >> > #include <sys/syscall.h> >> > ``` >> > >> > as the source of the syscall numbers because these header files come >> from >> > glibc. >> > >> > ``` >> > $ rpm -qf /usr/include/sys/syscall.h >> > glibc-headers-2.12-1.149.el6_6.5.x86_64 >> > $ rpm -qf /usr/include/unistd.h >> > glibc-headers-2.12-1.149.el6_6.5.x86_64 >> > ``` >> > >> > If use them, would fall into the problem @idownes mentioned in >> > `linux/ns.hpp` (Old glibc library and new kernel) >> > >> > ``` >> > #ifdef SYS_setns >> > int ret = ::syscall(SYS_setns, fd.get(), nstype.get()); >> > #elif __x86_64__ >> > // A workaround for those hosts that have an old glibc (older than >> > // 2.14) but have a new kernel. The magic number '308' here is the >> > // syscall number for 'setns' on x86_64 architecture. >> > int ret = ::syscall(308, fd.get(), nstype.get()); >> > #else >> > #error "setns is not available" >> > #endif >> > ``` >> > >> > I verify `#include <linux/unistd.h>` works on CentOS 6.5, CentOS 7.2 >> Ubuntu >> > 14.04 with X86 and Debian jessie with ARM. In code level, I verify it >> works >> > on all architectures I know [ >> > http://lxr.free-electrons.com/ident?v=3.8;i=__NR_pivot_root] . >> > >> > @BingLi would like to port Mesos works on System Z, and he blocked by >> > `__NR_pivot_root ` (https://issues.apache.org/jira/browse/MESOS-5242) >> as >> > well. As he commented in ticket, `#include <linux/unistd.h>` could solve >> > the problem as well. >> > >> > >> > Appendix[The verify program]: >> > >> > ``` >> > #include <linux/unistd.h> >> > #include <iostream> >> > >> > int main(int argc, char const *argv[]) >> > { >> > std::cout << __NR_pivot_root << std::endl; >> > return 0; >> > } >> > ``` >> > >> > >> > On Wed, Apr 27, 2016 at 3:24 AM, Benjamin Mahler <[email protected]> >> > wrote: >> > >> > > Looks like Vinod shipped MESOS-5121. I just shipped MESOS-5263 >> following >> > > the same approach. >> > > >> > > Haosdent mentioned some cleanups are possible here so please keep us >> > > posted if the cleanups are available! >> > > >> > > On Sun, Apr 24, 2016 at 1:34 PM, Tomek Janiszewski <[email protected] >> > >> > > wrote: >> > > >> > >> Hi, >> > >> >> > >> Can anyone shepherd https://issues.apache.org/jira/browse/MESOS-5263 >> ? >> > >> It's similar to https://issues.apache.org/jira/browse/MESOS-5121 and >> > >> could >> > >> be resolved in the same manner or it could be done in a way that'll >> > >> support >> > >> other platforms as well. >> > >> >> > >> Thanks >> > >> Tomek >> > >> >> > > >> > > >> > >> > >> > -- >> > Best Regards, >> > Haosdent Huang >> > >> > > > > -- > Best Regards, > Haosdent Huang > -- Best Regards, Haosdent Huang
