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
