| Message ID | 1404219488-11196-1-git-send-email-arei.gonglei@huawei.com |
|---|---|
| State | New |
| Headers | show |
On Tue, Jul 1, 2014 at 2:58 PM, <arei.gonglei@huawei.com> wrote: > From: Gonglei <arei.gonglei@huawei.com> > > because mmsghdr struct is introduced on Linux kernel 3.3+. > add check for mmsghdr struct, it only gets built on hosts that > support mmsghdr. > > Reported-by: chenliang <chenliang88@huawei.com> > Signed-off-by: Gonglei <arei.gonglei@huawei.com> > --- > v2->v1: > delete $l2tpv3 variable initialization and > 'if' false check suggested by PMM. > --- > configure | 16 ++++++++++++++++ > net/Makefile.objs | 2 +- > net/net.c | 4 ++-- > 3 files changed, 19 insertions(+), 3 deletions(-) Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
On 01/07/14 15:35, Stefan Hajnoczi wrote: > On Tue, Jul 1, 2014 at 2:58 PM, <arei.gonglei@huawei.com> wrote: >> From: Gonglei <arei.gonglei@huawei.com> >> >> because mmsghdr struct is introduced on Linux kernel 3.3+. >> add check for mmsghdr struct, it only gets built on hosts that >> support mmsghdr. Incorrect. mmsghdr itself is Linux 2.6.32 and so is recvmmsg. Sendmmsg which will be introduced in the next version of the patch is 3.0. None of them is 3.3+ Please see release notes for either kernel version. 2.6.32 is now 5 years old it is about time to update to relevant headers on whatever embedded platform you are using to try to build on. As far as general purpose linuxes, the relevant libc headers are present in Ubuntul LTS 12.x and onwards, Debian 7.x, Fedora, and all other major distros. I do not have a RHEL handy to check, but looking at release notes that the kernel supporting recmmsg is in 6.0 in the first place and so are the headers for glibc from certain point onwards. What appears in 3.3+ is kernel support for l2tpv3 tunnels which is what would allow a linux host to interop. A. >> >> Reported-by: chenliang <chenliang88@huawei.com> >> Signed-off-by: Gonglei <arei.gonglei@huawei.com> >> --- >> v2->v1: >> delete $l2tpv3 variable initialization and >> 'if' false check suggested by PMM. >> --- >> configure | 16 ++++++++++++++++ >> net/Makefile.objs | 2 +- >> net/net.c | 4 ++-- >> 3 files changed, 19 insertions(+), 3 deletions(-) > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
On 1 July 2014 16:06, Anton Ivanov (antivano) <antivano@cisco.com> wrote: > As far as general purpose linuxes, the relevant libc headers are present > in Ubuntul LTS 12.x and onwards, Debian 7.x, Fedora, and all other major > distros. I do not have a RHEL handy to check, but looking at release > notes that the kernel supporting recmmsg is in 6.0 in the first place > and so are the headers for glibc from certain point onwards. RHEL5 is still only 2.6.18 though (says wikipedia), so regardless of details of exactly which version this struct appeared in we still want to support compiling on a system which doesn't have it. (I'm planning to apply this patch to master for rc0; I'll fix up the commit message to quote a better version number.) thanks -- PMM
On 01/07/14 16:14, Peter Maydell wrote: > On 1 July 2014 16:06, Anton Ivanov (antivano) <antivano@cisco.com> wrote: >> As far as general purpose linuxes, the relevant libc headers are present >> in Ubuntul LTS 12.x and onwards, Debian 7.x, Fedora, and all other major >> distros. I do not have a RHEL handy to check, but looking at release >> notes that the kernel supporting recmmsg is in 6.0 in the first place >> and so are the headers for glibc from certain point onwards. > RHEL5 is still only 2.6.18 though (says wikipedia), so regardless of > details of exactly which version this struct appeared in we still want > to support compiling on a system which doesn't have it. > > (I'm planning to apply this patch to master for rc0; I'll fix up the > commit message to quote a better version number.) If we will support that far back, we need an emulation via recvmsg. I will provide an incremental which does that. I am not familiar with the way qemu ./configure tests are structured so if you can tell me which DEFINE I should use for the choice I will gladly supply the patch. A. > > thanks > -- PMM
On 1 July 2014 16:26, Anton Ivanov (antivano) <antivano@cisco.com> wrote: > On 01/07/14 16:14, Peter Maydell wrote: >> On 1 July 2014 16:06, Anton Ivanov (antivano) <antivano@cisco.com> wrote: >>> As far as general purpose linuxes, the relevant libc headers are present >>> in Ubuntul LTS 12.x and onwards, Debian 7.x, Fedora, and all other major >>> distros. I do not have a RHEL handy to check, but looking at release >>> notes that the kernel supporting recmmsg is in 6.0 in the first place >>> and so are the headers for glibc from certain point onwards. >> RHEL5 is still only 2.6.18 though (says wikipedia), so regardless of >> details of exactly which version this struct appeared in we still want >> to support compiling on a system which doesn't have it. >> >> (I'm planning to apply this patch to master for rc0; I'll fix up the >> commit message to quote a better version number.) > > If we will support that far back, we need an emulation via recvmsg. I > will provide an incremental which does that. We don't need to support this optional feature on RHEL5, we just need not to die horribly trying to compile it when we're on an older system, that's all. This patch should be enough for this, right? thanks -- PMM
On 01/07/14 16:34, Peter Maydell wrote: > On 1 July 2014 16:26, Anton Ivanov (antivano) <antivano@cisco.com> wrote: >> On 01/07/14 16:14, Peter Maydell wrote: >>> On 1 July 2014 16:06, Anton Ivanov (antivano) <antivano@cisco.com> wrote: >>>> As far as general purpose linuxes, the relevant libc headers are present >>>> in Ubuntul LTS 12.x and onwards, Debian 7.x, Fedora, and all other major >>>> distros. I do not have a RHEL handy to check, but looking at release >>>> notes that the kernel supporting recmmsg is in 6.0 in the first place >>>> and so are the headers for glibc from certain point onwards. >>> RHEL5 is still only 2.6.18 though (says wikipedia), so regardless of >>> details of exactly which version this struct appeared in we still want >>> to support compiling on a system which doesn't have it. >>> >>> (I'm planning to apply this patch to master for rc0; I'll fix up the >>> commit message to quote a better version number.) >> If we will support that far back, we need an emulation via recvmsg. I >> will provide an incremental which does that. > We don't need to support this optional feature on RHEL5, we > just need not to die horribly trying to compile it when we're > on an older system, that's all. This patch should be enough for > this, right? As a stop-gap - yes. An argument to configure which enables disables the feature should be good for now. I will try to supply a proper sendmms/recvmmsg configure test and appropriate wrappers and patches by the end of the week so they can be reused by anyone who wants to use sendmmsg/recvmmsg. The performance difference these provide is quite significant so it will be nice to port the legacy socket driver, etc to them too. A. > > thanks > -- PMM
On 1 July 2014 16:58, Anton Ivanov (antivano) <antivano@cisco.com> wrote: > On 01/07/14 16:34, Peter Maydell wrote: >> We don't need to support this optional feature on RHEL5, we >> just need not to die horribly trying to compile it when we're >> on an older system, that's all. This patch should be enough for >> this, right? > > As a stop-gap - yes. An argument to configure which enables disables > the feature should be good for now. This patch doesn't add any configure arguments: it just says "if there's no struct definition we won't build l2tpv3.c". thanks -- PMM
On 1 July 2014 13:58, <arei.gonglei@huawei.com> wrote: > From: Gonglei <arei.gonglei@huawei.com> > > because mmsghdr struct is introduced on Linux kernel 3.3+. > add check for mmsghdr struct, it only gets built on hosts that > support mmsghdr. > > Reported-by: chenliang <chenliang88@huawei.com> > Signed-off-by: Gonglei <arei.gonglei@huawei.com> Applied to master (with a tweaked commit message); thanks. -- PMM
> -----Original Message----- > From: Peter Maydell [mailto:peter.maydell@linaro.org] > Sent: Wednesday, July 02, 2014 1:27 AM > To: Gonglei (Arei) > Cc: QEMU Developers; Anton Ivanov (antivano); Stefan Hajnoczi; Paolo Bonzini; > Huangweidong (C); Luonengjun; chenliang (T) > Subject: Re: [PATCH v2] net: add mmsghdr struct check for L2TPV3 > > On 1 July 2014 13:58, <arei.gonglei@huawei.com> wrote: > > From: Gonglei <arei.gonglei@huawei.com> > > > > because mmsghdr struct is introduced on Linux kernel 3.3+. > > add check for mmsghdr struct, it only gets built on hosts that > > support mmsghdr. > > > > Reported-by: chenliang <chenliang88@huawei.com> > > Signed-off-by: Gonglei <arei.gonglei@huawei.com> > > Applied to master (with a tweaked commit message); thanks. > > -- PMM Ok, thank you. Best regards, -Gonglei
> -----Original Message----- > From: Anton Ivanov (antivano) [mailto:antivano@cisco.com] > Sent: Tuesday, July 01, 2014 11:06 PM > To: Stefan Hajnoczi; Gonglei (Arei) > Cc: qemu-devel; Peter Maydell; Huangweidong (C); chenliang (T); Luonengjun; > Stefan Hajnoczi; Paolo Bonzini > Subject: Re: [Qemu-devel] [PATCH v2] net: add mmsghdr struct check for > L2TPV3 > > On 01/07/14 15:35, Stefan Hajnoczi wrote: > > On Tue, Jul 1, 2014 at 2:58 PM, <arei.gonglei@huawei.com> wrote: > >> From: Gonglei <arei.gonglei@huawei.com> > >> > >> because mmsghdr struct is introduced on Linux kernel 3.3+. > >> add check for mmsghdr struct, it only gets built on hosts that > >> support mmsghdr. > > Incorrect. > > mmsghdr itself is Linux 2.6.32 and so is recvmmsg. Sendmmsg which will > be introduced in the next version of the patch is 3.0. None of them is 3.3+ > > Please see release notes for either kernel version. > Sorry for my incorrect reference. Actually, my host is : UVP:~ # uname -a Linux UVP 3.0.93-0.8-default #1 SMP Tue Aug 27 08:44:18 UTC 2013 (70ed288) x86_64 x86_64 x86_64 GNU/Linux UVP:~ # cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 3 But it is not Linux 2.6.32 or more lower-:) Best regards, -Gonglei > 2.6.32 is now 5 years old it is about time to update to relevant headers > on whatever embedded platform you are using to try to build on. > > As far as general purpose linuxes, the relevant libc headers are present > in Ubuntul LTS 12.x and onwards, Debian 7.x, Fedora, and all other major > distros. I do not have a RHEL handy to check, but looking at release > notes that the kernel supporting recmmsg is in 6.0 in the first place > and so are the headers for glibc from certain point onwards. > > What appears in 3.3+ is kernel support for l2tpv3 tunnels which is what > would allow a linux host to interop. > > A. > > >> > >> Reported-by: chenliang <chenliang88@huawei.com> > >> Signed-off-by: Gonglei <arei.gonglei@huawei.com> > >> --- > >> v2->v1: > >> delete $l2tpv3 variable initialization and > >> 'if' false check suggested by PMM. > >> --- > >> configure | 16 ++++++++++++++++ > >> net/Makefile.objs | 2 +- > >> net/net.c | 4 ++-- > >> 3 files changed, 19 insertions(+), 3 deletions(-) > > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
diff --git a/configure b/configure index 23ecb37..463ae6e 100755 --- a/configure +++ b/configure @@ -1712,6 +1712,19 @@ else fi ########################################## +# L2TPV3 probe + +cat > $TMPC <<EOF +#include <sys/socket.h> +int main(void) { return sizeof(struct mmsghdr); } +EOF +if compile_prog "" "" ; then + l2tpv3=yes +else + l2tpv3=no +fi + +########################################## # pkg-config probe if ! has "$pkg_config_exe"; then @@ -4343,6 +4356,9 @@ fi if test "$netmap" = "yes" ; then echo "CONFIG_NETMAP=y" >> $config_host_mak fi +if test "$l2tpv3" = "yes" ; then + echo "CONFIG_L2TPV3=y" >> $config_host_mak +fi if test "$cap_ng" = "yes" ; then echo "CONFIG_LIBCAP=y" >> $config_host_mak fi diff --git a/net/Makefile.objs b/net/Makefile.objs index a06ba59..ec19cb3 100644 --- a/net/Makefile.objs +++ b/net/Makefile.objs @@ -2,7 +2,7 @@ common-obj-y = net.o queue.o checksum.o util.o hub.o common-obj-y += socket.o common-obj-y += dump.o common-obj-y += eth.o -common-obj-$(CONFIG_LINUX) += l2tpv3.o +common-obj-$(CONFIG_L2TPV3) += l2tpv3.o common-obj-$(CONFIG_POSIX) += tap.o vhost-user.o common-obj-$(CONFIG_LINUX) += tap-linux.o common-obj-$(CONFIG_WIN32) += tap-win32.o diff --git a/net/net.c b/net/net.c index 0869c60..6d930ea 100644 --- a/net/net.c +++ b/net/net.c @@ -806,7 +806,7 @@ static int (* const net_client_init_fun[NET_CLIENT_OPTIONS_KIND_MAX])( #ifdef CONFIG_VHOST_NET_USED [NET_CLIENT_OPTIONS_KIND_VHOST_USER] = net_init_vhost_user, #endif -#ifdef CONFIG_LINUX +#ifdef CONFIG_L2TPV3 [NET_CLIENT_OPTIONS_KIND_L2TPV3] = net_init_l2tpv3, #endif }; @@ -845,7 +845,7 @@ static int net_client_init1(const void *object, int is_netdev, Error **errp) #ifdef CONFIG_VHOST_NET_USED case NET_CLIENT_OPTIONS_KIND_VHOST_USER: #endif -#ifdef CONFIG_LINUX +#ifdef CONFIG_L2TPV3 case NET_CLIENT_OPTIONS_KIND_L2TPV3: #endif break;