Didn't see your email until now, but just to update the list this was committed.
On Fri, May 6, 2016 at 9:14 AM, haosdent <[email protected]> wrote: > 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 >
