Re: Looking for Shepherd for MESOS-5263

[haosdent]

ping @ben and @vinodkone, would you like to review this patch again?

On Wed, Apr 27, 2016 at 7:22 PM, haosdent  wrote:

> Already left my comments on it, thank you for your patch!
>
> On Wed, Apr 27, 2016 at 5:52 PM, Tomek Janiszewski 
> 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  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 
>> > ```
>> >
>> > 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 
>> > #include 
>> > ```
>> >
>> > 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 ` 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 ` could solve
>> > the problem as well.
>> >
>> >
>> > Appendix[The verify program]:
>> >
>> > ```
>> > #include 
>> > #include 
>> >
>> > 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 
>> > 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 > >
>> > > 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

[haosdent]

Already left my comments on it, thank you for your patch!

On Wed, Apr 27, 2016 at 5:52 PM, Tomek Janiszewski 
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  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 
> > ```
> >
> > 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 
> > #include 
> > ```
> >
> > 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 ` 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 ` could solve
> > the problem as well.
> >
> >
> > Appendix[The verify program]:
> >
> > ```
> > #include 
> > #include 
> >
> > 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 
> > 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 
> > > 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

Re: Looking for Shepherd for MESOS-5263

[Tomek Janiszewski]

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  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 
> ```
>
> 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 
> #include 
> ```
>
> 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 ` 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 ` could solve
> the problem as well.
>
>
> Appendix[The verify program]:
>
> ```
> #include 
> #include 
>
> 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 
> 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 
> > 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
>

Re: Looking for Shepherd for MESOS-5263

[haosdent]

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 
```

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 
#include 
```

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 ` 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 ` could solve
the problem as well.


Appendix[The verify program]:

```
#include 
#include 

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  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 
> 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

Re: Looking for Shepherd for MESOS-5263

[Benjamin Mahler]

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 
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
>

Looking for Shepherd for MESOS-5263

[Tomek Janiszewski]

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