You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by haosdent <ha...@gmail.com> on 2016/05/06 16:14:53 UTC
Re: Looking for Shepherd for MESOS-5263
ping @ben and @vinodkone, would you like to review this patch again?
On Wed, Apr 27, 2016 at 7:22 PM, haosdent <ha...@gmail.com> wrote:
> Already left my comments on it, thank you for your patch!
>
> On Wed, Apr 27, 2016 at 5:52 PM, Tomek Janiszewski <ja...@gmail.com>
> 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 <ha...@gmail.com> 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 <bm...@apache.org>
>> > 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 <janiszt@gmail.com
>> >
>> > > 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
Re: Looking for Shepherd for MESOS-5263
Posted by Benjamin Mahler <bm...@apache.org>.
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 <ha...@gmail.com> wrote:
> ping @ben and @vinodkone, would you like to review this patch again?
>
> On Wed, Apr 27, 2016 at 7:22 PM, haosdent <ha...@gmail.com> wrote:
>
>> Already left my comments on it, thank you for your patch!
>>
>> On Wed, Apr 27, 2016 at 5:52 PM, Tomek Janiszewski <ja...@gmail.com>
>> 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 <ha...@gmail.com>
>>> 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 <bm...@apache.org>
>>> > 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 <
>>> janiszt@gmail.com>
>>> > > 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
>