* [PATCH 0/3] selftests: ptrace, kcmp, efivars build failure fixes
From: Shuah Khan @ 2015-03-10 22:00 UTC (permalink / raw)
To: gorcunov-GEFAQzZX7r8dnm+yROfE0A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w, mpe-Gsx/Oe8HsFggBc27wqDAHg
Cc: Shuah Khan, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
ptrace, efivars, and kcmp Makefiles don't have explicit build rule.
As a result, build fails when make is run from top level Makefile
target kselftest. Without the explicit rule, make works only when
it is run in the current directory or from selftests directory.
Fxing the problems by adding an explicit build rule to fix the
problem.
Shuah Khan (3):
selftests: ptrace build fails when invoked from kselftest target
selftests: efivars build fails when invoked from kselftest target
selftests: kcmp build fails when invoked from kselftest target
tools/testing/selftests/efivarfs/Makefile | 2 ++
tools/testing/selftests/kcmp/Makefile | 5 +++--
tools/testing/selftests/ptrace/Makefile | 5 +++--
3 files changed, 8 insertions(+), 4 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH 1/3] selftests: ptrace build fails when invoked from kselftest target
From: Shuah Khan @ 2015-03-10 22:00 UTC (permalink / raw)
To: gorcunov-GEFAQzZX7r8dnm+yROfE0A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w, mpe-Gsx/Oe8HsFggBc27wqDAHg
Cc: Shuah Khan, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1426022048.git.shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
ptrace Makefile doesn't have an explicit build rule. As a result,
ptrace build fails, when it is run from top level Makefile target
kselftest. Without the explicit rule, make works only when it is
run in the current directory or from selftests directory. Add an
explicit build rule to fix the problem.
Signed-off-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
tools/testing/selftests/ptrace/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/ptrace/Makefile b/tools/testing/selftests/ptrace/Makefile
index 47ae2d3..9067567 100644
--- a/tools/testing/selftests/ptrace/Makefile
+++ b/tools/testing/selftests/ptrace/Makefile
@@ -1,7 +1,8 @@
+CC := $(CROSS_COMPILE)$(CC)
CFLAGS += -iquote../../../../include/uapi -Wall
-peeksiginfo: peeksiginfo.c
-all: peeksiginfo
+all:
+ $(CC) $(CFLAGS) peeksiginfo.c -o peeksiginfo
clean:
rm -f peeksiginfo
--
2.1.0
^ permalink raw reply related
* [PATCH 2/3] selftests: efivars build fails when invoked from kselftest target
From: Shuah Khan @ 2015-03-10 22:00 UTC (permalink / raw)
To: gorcunov-GEFAQzZX7r8dnm+yROfE0A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w, mpe-Gsx/Oe8HsFggBc27wqDAHg
Cc: Shuah Khan, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1426022048.git.shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
efivars Makefile doesn't have an explicit build rule. As a result,
efivars build fails, when it is run from top level Makefile target
kselftest. Without the explicit rule, make works only when it is
run in the current directory or from selftests directory. Add an
explicit build rule to fix the problem.
Signed-off-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
tools/testing/selftests/efivarfs/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/efivarfs/Makefile b/tools/testing/selftests/efivarfs/Makefile
index 29e8c6b..bb48d73 100644
--- a/tools/testing/selftests/efivarfs/Makefile
+++ b/tools/testing/selftests/efivarfs/Makefile
@@ -4,6 +4,8 @@ CFLAGS = -Wall
test_objs = open-unlink create-read
all: $(test_objs)
+%: %.c
+ $(CC) $(CFLAGS) -o $@ $^
run_tests: all
@/bin/bash ./efivarfs.sh || echo "efivarfs selftests: [FAIL]"
--
2.1.0
^ permalink raw reply related
* [PATCH 3/3] selftests: kcmp build fails when invoked from kselftest target
From: Shuah Khan @ 2015-03-10 22:00 UTC (permalink / raw)
To: gorcunov, akpm, tranmanphong, mpe; +Cc: Shuah Khan, linux-kernel, linux-api
In-Reply-To: <cover.1426022048.git.shuahkh@osg.samsung.com>
kcmp Makefile doesn't have an explicit build rule. As a result,
kcmp build fails, when it is run from top level Makefile target
kselftest. Without the explicit rule, make works only when it is
run in the current directory or from selftests directory. Add an
explicit build rule to fix the problem. In addition, build fails
as it can't find kcmp.h. Fix it by passing CFLAGS.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
---
tools/testing/selftests/kcmp/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kcmp/Makefile b/tools/testing/selftests/kcmp/Makefile
index ff0eefd..83383eb 100644
--- a/tools/testing/selftests/kcmp/Makefile
+++ b/tools/testing/selftests/kcmp/Makefile
@@ -1,7 +1,8 @@
CC := $(CROSS_COMPILE)$(CC)
-CFLAGS += -I../../../../usr/include/
+CFLAGS += -I../../../../include/uapi -I../../../../usr/include/
-all: kcmp_test
+all:
+ $(CC) $(CFLAGS) kcmp_test.c -o kcmp_test
run_tests: all
@./kcmp_test || echo "kcmp_test: [FAIL]"
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 3/3] selftests: kcmp build fails when invoked from kselftest target
From: Cyrill Gorcunov @ 2015-03-10 22:09 UTC (permalink / raw)
To: Shuah Khan
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w, mpe-Gsx/Oe8HsFggBc27wqDAHg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <80f321919d8d1f804c4933acac9b044d4c6626eb.1426022048.git.shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Tue, Mar 10, 2015 at 04:00:59PM -0600, Shuah Khan wrote:
> kcmp Makefile doesn't have an explicit build rule. As a result,
> kcmp build fails, when it is run from top level Makefile target
> kselftest. Without the explicit rule, make works only when it is
> run in the current directory or from selftests directory. Add an
> explicit build rule to fix the problem. In addition, build fails
> as it can't find kcmp.h. Fix it by passing CFLAGS.
>
> Signed-off-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> ---
> tools/testing/selftests/kcmp/Makefile | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/kcmp/Makefile b/tools/testing/selftests/kcmp/Makefile
> index ff0eefd..83383eb 100644
> --- a/tools/testing/selftests/kcmp/Makefile
> +++ b/tools/testing/selftests/kcmp/Makefile
> @@ -1,7 +1,8 @@
> CC := $(CROSS_COMPILE)$(CC)
> -CFLAGS += -I../../../../usr/include/
> +CFLAGS += -I../../../../include/uapi -I../../../../usr/include/
>
> -all: kcmp_test
> +all:
> + $(CC) $(CFLAGS) kcmp_test.c -o kcmp_test
>
> run_tests: all
> @./kcmp_test || echo "kcmp_test: [FAIL]"
Ho Shuah! Thanks for looking into it. I've a small question --
why kcmp_test prerequsite is dropped? As to me it should remain
here, except explicit build rule added.
^ permalink raw reply
* Re: [PATCH 3/3] selftests: kcmp build fails when invoked from kselftest target
From: Shuah Khan @ 2015-03-10 22:41 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w, mpe-Gsx/Oe8HsFggBc27wqDAHg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150310220954.GL30296@moon>
On 03/10/2015 04:09 PM, Cyrill Gorcunov wrote:
> On Tue, Mar 10, 2015 at 04:00:59PM -0600, Shuah Khan wrote:
>> kcmp Makefile doesn't have an explicit build rule. As a result,
>> kcmp build fails, when it is run from top level Makefile target
>> kselftest. Without the explicit rule, make works only when it is
>> run in the current directory or from selftests directory. Add an
>> explicit build rule to fix the problem. In addition, build fails
>> as it can't find kcmp.h. Fix it by passing CFLAGS.
>>
>> Signed-off-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>> ---
>> tools/testing/selftests/kcmp/Makefile | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/testing/selftests/kcmp/Makefile b/tools/testing/selftests/kcmp/Makefile
>> index ff0eefd..83383eb 100644
>> --- a/tools/testing/selftests/kcmp/Makefile
>> +++ b/tools/testing/selftests/kcmp/Makefile
>> @@ -1,7 +1,8 @@
>> CC := $(CROSS_COMPILE)$(CC)
>> -CFLAGS += -I../../../../usr/include/
>> +CFLAGS += -I../../../../include/uapi -I../../../../usr/include/
>>
>> -all: kcmp_test
>> +all:
>> + $(CC) $(CFLAGS) kcmp_test.c -o kcmp_test
>>
>> run_tests: all
>> @./kcmp_test || echo "kcmp_test: [FAIL]"
>
> Ho Shuah! Thanks for looking into it. I've a small question --
> why kcmp_test prerequsite is dropped? As to me it should remain
> here, except explicit build rule added.
>
Are you looking for something like this:
all: kcmp_test
kcmp_test:
$(CC) $(CFLAGS) kcmp_test.c -o kcmp_test
I just simplified it and removed the prerequsite.
If you prefer, I can make the change to keep the
prereq.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* Re: [PATCH 3/3] selftests: kcmp build fails when invoked from kselftest target
From: Cyrill Gorcunov @ 2015-03-10 22:45 UTC (permalink / raw)
To: Shuah Khan; +Cc: akpm, tranmanphong, mpe, linux-kernel, linux-api
In-Reply-To: <54FF7323.2080603@osg.samsung.com>
On Tue, Mar 10, 2015 at 04:41:39PM -0600, Shuah Khan wrote:
>
> Are you looking for something like this:
>
> all: kcmp_test
>
> kcmp_test:
> $(CC) $(CFLAGS) kcmp_test.c -o kcmp_test
>
> I just simplified it and removed the prerequsite.
> If you prefer, I can make the change to keep the
> prereq.
Yes please, and you may use internal make var $@ as well
kcmp_test:
$(CC) $(CFLAGS) kcmp_test.c -o $@
^ permalink raw reply
* Re: [PATCH 15/45] dm-log-userspace.h: include stdint.h in userspace
From: Mikko Rapeli @ 2015-03-10 22:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alasdair G Kergon, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Mike Snitzer, dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2286739.alIuOL4vnt@wuerfel>
On Tue, Feb 17, 2015 at 02:55:49PM +0100, Arnd Bergmann wrote:
> On Tuesday 17 February 2015 13:38:06 Alasdair G Kergon wrote:
> > On Tue, Feb 17, 2015 at 10:08:56AM +0100, Arnd Bergmann wrote:
> > > The normal way to do this in kernel headers is to use linux/types.h
> > > but change the data structures to use __u64 instead of uint64_t
> > > to avoid the build error.
> >
> > That's what happened to dm-ioctl.h.
>
> Ah, indeed. It turns out that it was my own change that did this:
>
>
> commit 9adfbfb611307060db54691bc7e6d53fdc12312b
> Author: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Date: Thu Feb 26 00:51:40 2009 +0100
>
> make most exported headers use strict integer types
>
> This takes care of all files that have only a small number
> of non-strict integer type uses.
>
> > (Or someone could adjust linux/types.h to include these as standard.)
>
> No, that wouldn't work. The C user space headers are not meant to
> be included implicitly by any standard headers, which might pull
> in linux/types.h implicitly.
>
> I think it would be best to change all patches in the new series
> in the same way for consistency and try to avoid using stdint.h
> as much as we can.
Ok, I'll change all patches to use __u8 etc types instead of uint8_t etc via
stdint.h.
-Mikko
^ permalink raw reply
* Re: [Xen-devel] [PATCH 25/45] gntalloc.h: include stdint.h in userspace
From: Mikko Rapeli @ 2015-03-10 22:48 UTC (permalink / raw)
To: David Vrabel
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b, Boris Ostrovsky
In-Reply-To: <54E47D32.9040208-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
On Wed, Feb 18, 2015 at 11:53:22AM +0000, David Vrabel wrote:
> On 16/02/15 23:05, Mikko Rapeli wrote:
> > Fixes compilation error:
> >
> > xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’
> >
> > Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
> > ---
> > include/uapi/xen/gntalloc.h | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/include/uapi/xen/gntalloc.h b/include/uapi/xen/gntalloc.h
> > index 76bd580..184df7e 100644
> > --- a/include/uapi/xen/gntalloc.h
> > +++ b/include/uapi/xen/gntalloc.h
> > @@ -11,6 +11,12 @@
> > #ifndef __LINUX_PUBLIC_GNTALLOC_H__
> > #define __LINUX_PUBLIC_GNTALLOC_H__
> >
> > +#ifdef __KERNEL__
> > +#include <linux/types.h>
> > +#else
> > +#include <stdint.h>
> > +#endif
>
> I think it would be preferrable to #include <linux/types.h> only and
> switch to using the __u32 etc. types (as others have suggested).
Yes, I'm changes the patches to these.
-Mikko
^ permalink raw reply
* Re: [PATCH 33/45] include/uapi/asm-generic/signal.h: include stdlib.h in userspace
From: Mikko Rapeli @ 2015-03-10 22:58 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel, linux-arch, linux-api
In-Reply-To: <2372547.aJh8O9JSDy@wuerfel>
On Tue, Feb 17, 2015 at 10:44:48AM +0100, Arnd Bergmann wrote:
> On Tuesday 17 February 2015 00:05:36 Mikko Rapeli wrote:
> > Fixes compiler warning:
> > error: unknown type name ‘size_t’
> >
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> > ---
> > include/uapi/asm-generic/signal.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/include/uapi/asm-generic/signal.h b/include/uapi/asm-generic/signal.h
> > index 9df61f1..8a341a2 100644
> > --- a/include/uapi/asm-generic/signal.h
> > +++ b/include/uapi/asm-generic/signal.h
> > @@ -3,6 +3,10 @@
> >
> > #include <linux/types.h>
> >
> > +#ifndef __KERNEL__
> > +#include <stdlib.h>
> > +#endif
> > +
>
> Hmm, maybe we should use __kernel_size_t instead?
This problem is in several uapi header files on x86:
asm-generic/shmbuf.h
asm-generic/signal.h
asm/signal.h
drm/drm.h
linux/agpgart.h
linux/kexec.h
linux/ncp_fs.h
linux/nfc.h
linux/omapfb.h
linux/reiserfs_xattr.h
linux/sysctl.h
sound/asound.h
so I guess using __kernel_size_t is the correct approach for all of them,
right?
linux/kexec.h seems suspicious though:
#ifndef __KERNEL__
/*
* This structure is used to hold the arguments that are used when
* loading kernel binaries.
*/
struct kexec_segment {
const void *buf;
size_t bufsz;
const void *mem;
size_t memsz;
};
#endif /* __KERNEL__ */
-Mikko
^ permalink raw reply
* Re: [PATCH 0/3] selftests: ptrace, kcmp, efivars build failure fixes
From: Michael Ellerman @ 2015-03-10 23:35 UTC (permalink / raw)
To: Shuah Khan
Cc: gorcunov-GEFAQzZX7r8dnm+yROfE0A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1426022048.git.shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Tue, 2015-03-10 at 16:00 -0600, Shuah Khan wrote:
> ptrace, efivars, and kcmp Makefiles don't have explicit build rule.
> As a result, build fails when make is run from top level Makefile
> target kselftest. Without the explicit rule, make works only when
> it is run in the current directory or from selftests directory.
> Fxing the problems by adding an explicit build rule to fix the
> problem.
>
> Shuah Khan (3):
> selftests: ptrace build fails when invoked from kselftest target
> selftests: efivars build fails when invoked from kselftest target
> selftests: kcmp build fails when invoked from kselftest target
>
> tools/testing/selftests/efivarfs/Makefile | 2 ++
> tools/testing/selftests/kcmp/Makefile | 5 +++--
> tools/testing/selftests/ptrace/Makefile | 5 +++--
> 3 files changed, 8 insertions(+), 4 deletions(-)
What? No. This is the bug my patch to filter the make flags fixes.
cheers
^ permalink raw reply
* Re: [PATCH] kbuild: Don't pass -rR to selftest makefiles
From: Michael Ellerman @ 2015-03-10 23:36 UTC (permalink / raw)
To: Shuah Khan
Cc: mmarek-AlSwsSmVLrQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
davej-rdkfGonbjUTCLXcRTR1eJlpr/1R2p/CL,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <54FE2377.9040709-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Mon, 2015-03-09 at 16:49 -0600, Shuah Khan wrote:
> On 03/09/2015 08:28 AM, Shuah Khan wrote:
> > On 03/04/2015 03:19 AM, Michael Ellerman wrote:
> >> The makefiles under tools/testing/selftests are not real kbuild
> >> makefiles, they are regular stand alone makefiles. As such they *do*
> >> want all the standard implicit rules and variables defined.
> >>
> >> So before calling those makefiles, filter -rR out of MAKEFLAGS.
> >>
> >> Without this not all the selftests are built correctly when called via
> >> the top-level Makefile.
> >>
> >> Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
> >
> > Hi Michal,
> >
> > Could you please take this patch in your tree.
> >
> > Acked-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> >
>
> I am changing this to a Nack. This is not fully cooked.
> I am seeing new failures on some tests.
>
> gcc: error: elf_x86_64: No such file or directory
> gcc: error: unrecognized command line option ‘-m’
I can't reproduce that here. In what way do you think it's related to this
patch?
cheers
^ permalink raw reply
* Re: [PATCH 0/3] selftests: ptrace, kcmp, efivars build failure fixes
From: Shuah Khan @ 2015-03-10 23:37 UTC (permalink / raw)
To: Michael Ellerman
Cc: gorcunov-GEFAQzZX7r8dnm+yROfE0A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1426030513.20917.2.camel-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
On 03/10/2015 05:35 PM, Michael Ellerman wrote:
> On Tue, 2015-03-10 at 16:00 -0600, Shuah Khan wrote:
>> ptrace, efivars, and kcmp Makefiles don't have explicit build rule.
>> As a result, build fails when make is run from top level Makefile
>> target kselftest. Without the explicit rule, make works only when
>> it is run in the current directory or from selftests directory.
>> Fxing the problems by adding an explicit build rule to fix the
>> problem.
>>
>> Shuah Khan (3):
>> selftests: ptrace build fails when invoked from kselftest target
>> selftests: efivars build fails when invoked from kselftest target
>> selftests: kcmp build fails when invoked from kselftest target
>>
>> tools/testing/selftests/efivarfs/Makefile | 2 ++
>> tools/testing/selftests/kcmp/Makefile | 5 +++--
>> tools/testing/selftests/ptrace/Makefile | 5 +++--
>> 3 files changed, 8 insertions(+), 4 deletions(-)
>
> What? No. This is the bug my patch to filter the make flags fixes.
>
> cheers
>
>
Michael,
Did you see my email from yesterday on how your patch introduced
more problems. Can you please make sure the patches you send work
and don't introduce problems. I am having this issue with a lot
of your patches.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* Re: [PATCH] kbuild: Don't pass -rR to selftest makefiles
From: Shuah Khan @ 2015-03-10 23:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: mmarek, linux-kernel, davej, linux-api
In-Reply-To: <1426030567.20917.3.camel@ellerman.id.au>
On 03/10/2015 05:36 PM, Michael Ellerman wrote:
> On Mon, 2015-03-09 at 16:49 -0600, Shuah Khan wrote:
>> On 03/09/2015 08:28 AM, Shuah Khan wrote:
>>> On 03/04/2015 03:19 AM, Michael Ellerman wrote:
>>>> The makefiles under tools/testing/selftests are not real kbuild
>>>> makefiles, they are regular stand alone makefiles. As such they *do*
>>>> want all the standard implicit rules and variables defined.
>>>>
>>>> So before calling those makefiles, filter -rR out of MAKEFLAGS.
>>>>
>>>> Without this not all the selftests are built correctly when called via
>>>> the top-level Makefile.
>>>>
>>>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>>>
>>> Hi Michal,
>>>
>>> Could you please take this patch in your tree.
>>>
>>> Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
>>>
>>
>> I am changing this to a Nack. This is not fully cooked.
>> I am seeing new failures on some tests.
>>
>> gcc: error: elf_x86_64: No such file or directory
>> gcc: error: unrecognized command line option ‘-m’
>
> I can't reproduce that here. In what way do you think it's related to this
> patch?
>
> cheers
I have just your patch on tops of linux 4.0-rc3 and ran
make kselftest and that's what I see.
If you can fix this problem I can take your patch, otherwise,
I have to go with individual Makefiles fixes.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply
* Re: [PATCH 0/3] selftests: ptrace, kcmp, efivars build failure fixes
From: Shuah Khan @ 2015-03-10 23:40 UTC (permalink / raw)
To: Michael Ellerman
Cc: gorcunov-GEFAQzZX7r8dnm+yROfE0A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <54FF803E.9030407-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On 03/10/2015 05:37 PM, Shuah Khan wrote:
> On 03/10/2015 05:35 PM, Michael Ellerman wrote:
>> On Tue, 2015-03-10 at 16:00 -0600, Shuah Khan wrote:
>>> ptrace, efivars, and kcmp Makefiles don't have explicit build rule.
>>> As a result, build fails when make is run from top level Makefile
>>> target kselftest. Without the explicit rule, make works only when
>>> it is run in the current directory or from selftests directory.
>>> Fxing the problems by adding an explicit build rule to fix the
>>> problem.
>>>
>>> Shuah Khan (3):
>>> selftests: ptrace build fails when invoked from kselftest target
>>> selftests: efivars build fails when invoked from kselftest target
>>> selftests: kcmp build fails when invoked from kselftest target
>>>
>>> tools/testing/selftests/efivarfs/Makefile | 2 ++
>>> tools/testing/selftests/kcmp/Makefile | 5 +++--
>>> tools/testing/selftests/ptrace/Makefile | 5 +++--
>>> 3 files changed, 8 insertions(+), 4 deletions(-)
>>
>> What? No. This is the bug my patch to filter the make flags fixes.
>>
>> cheers
>>
>>
>
> Michael,
>
> Did you see my email from yesterday on how your patch introduced
> more problems. Can you please make sure the patches you send work
> and don't introduce problems. I am having this issue with a lot
> of your patches.
>
btw your patch doesn't fix the header file include problem. I don't
see any reason why individual Makefile shouldn't address this problem.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* Re: [PATCH] kbuild: Don't pass -rR to selftest makefiles
From: Michael Ellerman @ 2015-03-10 23:49 UTC (permalink / raw)
To: Shuah Khan
Cc: mmarek-AlSwsSmVLrQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
davej-rdkfGonbjUTCLXcRTR1eJlpr/1R2p/CL,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <54FF809F.7020205-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Tue, 2015-03-10 at 17:39 -0600, Shuah Khan wrote:
> On 03/10/2015 05:36 PM, Michael Ellerman wrote:
> > On Mon, 2015-03-09 at 16:49 -0600, Shuah Khan wrote:
> >> On 03/09/2015 08:28 AM, Shuah Khan wrote:
> >>> On 03/04/2015 03:19 AM, Michael Ellerman wrote:
> >>>> The makefiles under tools/testing/selftests are not real kbuild
> >>>> makefiles, they are regular stand alone makefiles. As such they *do*
> >>>> want all the standard implicit rules and variables defined.
> >>>>
> >>>> So before calling those makefiles, filter -rR out of MAKEFLAGS.
> >>>>
> >>>> Without this not all the selftests are built correctly when called via
> >>>> the top-level Makefile.
> >>>>
> >>>> Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
> >>>
> >>> Hi Michal,
> >>>
> >>> Could you please take this patch in your tree.
> >>>
> >>> Acked-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> >>>
> >>
> >> I am changing this to a Nack. This is not fully cooked.
> >> I am seeing new failures on some tests.
> >>
> >> gcc: error: elf_x86_64: No such file or directory
> >> gcc: error: unrecognized command line option ‘-m’
> >
> > I can't reproduce that here. In what way do you think it's related to this
> > patch?
>
> I have just your patch on tops of linux 4.0-rc3 and ran
> make kselftest and that's what I see.
>
> If you can fix this problem I can take your patch, otherwise,
> I have to go with individual Makefiles fixes.
OK I see it now, only happens on x86.
It looks like it's coming in via kbuild. Though I can only see it being set in
arch/x86/Makefile.um, and I don't know why that is being sourced. But it must
be.
So this is another symptom of running via the top-level Makefile rather than
directly.
I'll try and find a fix.
cheers
^ permalink raw reply
* Re: [PATCH 34/45] include/uapi/asm-generic/signal.h: hide sigset_t definition in userspace
From: Mikko Rapeli @ 2015-03-11 0:05 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel, linux-arch, linux-api
In-Reply-To: <2741317.tcRFXAy9C6@wuerfel>
On Tue, Feb 17, 2015 at 10:16:09AM +0100, Arnd Bergmann wrote:
> On Tuesday 17 February 2015 00:05:37 Mikko Rapeli wrote:
> > +#ifdef __KERNEL__
> > +/* already defined in userspace via stdlib.h */
> > typedef struct {
> > unsigned long sig[_NSIG_WORDS];
> > } sigset_t;
> > +#endif /* __KERNEL__ */
>
> I'm not sure here: Is this structure always identical to the one
> we see in user space?
>
> If not, we might want to rename the typedef to __kernel_sigset_t
> instead and use that inside of the uapi headers.
I was copying this ifdef from the struct sigaction part in the same file:
#ifndef __KERNEL__
struct sigaction {
__sighandler_t sa_handler;
unsigned long sa_flags;
#ifdef SA_RESTORER
__sigrestore_t sa_restorer;
#endif
sigset_t sa_mask; /* mask last for extensibility */
};
#endif
I assumed it had the same problems at some point.
-Mikko
^ permalink raw reply
* [PATCH v2] selftests: kcmp build fails when invoked from kselftest target
From: Shuah Khan @ 2015-03-11 0:08 UTC (permalink / raw)
To: gorcunov-GEFAQzZX7r8dnm+yROfE0A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tranmanphong-Re5JQEeQqe8AvxtiuMwx3w, mpe-Gsx/Oe8HsFggBc27wqDAHg
Cc: Shuah Khan, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
kcmp Makefile doesn't have an explicit build rule. As a result,
kcmp build fails, when it is run from top level Makefile target
kselftest. Without the explicit rule, make works only when it is
run in the current directory or from selftests directory. Add an
explicit build rule to fix the problem. In addition, build fails
as it can't find kcmp.h. Fix it by passing CFLAGS.
Signed-off-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
v2: Added deleted pre-requisite back in to address review
comments.
tools/testing/selftests/kcmp/Makefile | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kcmp/Makefile b/tools/testing/selftests/kcmp/Makefile
index ff0eefd..d615e9c 100644
--- a/tools/testing/selftests/kcmp/Makefile
+++ b/tools/testing/selftests/kcmp/Makefile
@@ -1,8 +1,11 @@
CC := $(CROSS_COMPILE)$(CC)
-CFLAGS += -I../../../../usr/include/
+CFLAGS += -I../../../../include/uapi -I../../../../usr/include/
all: kcmp_test
+kcmp_test:
+ $(CC) $(CFLAGS) kcmp_test.c -o kcmp_test
+
run_tests: all
@./kcmp_test || echo "kcmp_test: [FAIL]"
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 24/45] hdspm.h: include stdint.h in userspace
From: Mikko Rapeli @ 2015-03-11 0:28 UTC (permalink / raw)
To: Takashi Iwai, Arnd Bergmann
Cc: linux-kernel, Jaroslav Kysela, alsa-devel, linux-api
In-Reply-To: <s5hwq3hox1x.wl-tiwai@suse.de>
On Tue, Feb 17, 2015 at 07:46:02AM +0100, Takashi Iwai wrote:
> At Tue, 17 Feb 2015 00:05:27 +0100,
> Mikko Rapeli wrote:
> >
> > Fixes compilation error:
> >
> > sound/hdspm.h:43:2: error: unknown type name ‘uint32_t’
> >
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
>
> Applied for 3.21, thanks.
Sorry, but this should maybe be dropped or reverted from the sound tree.
Arnd and others pointed out that kernel headers should be using __u32 etc
types from linux/types.h instead of including stdint.h from libc and using
uint32_t et al.
I'll post a new patch version for hdspm.h too in the next revision.
-Mikko
>
> Takashi
>
> > ---
> > include/uapi/sound/hdspm.h | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/include/uapi/sound/hdspm.h b/include/uapi/sound/hdspm.h
> > index d956c35..f799828 100644
> > --- a/include/uapi/sound/hdspm.h
> > +++ b/include/uapi/sound/hdspm.h
> > @@ -20,6 +20,12 @@
> > * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> > */
> >
> > +#ifdef __KERNEL__
> > +#include <linux/types.h>
> > +#else
> > +#include <stdint.h>
> > +#endif
> > +
> > /* Maximum channels is 64 even on 56Mode you have 64playbacks to matrix */
> > #define HDSPM_MAX_CHANNELS 64
> >
> > --
> > 2.1.4
> >
^ permalink raw reply
* Re: [PATCH] kbuild: Don't pass -rR to selftest makefiles
From: Shuah Khan @ 2015-03-11 0:35 UTC (permalink / raw)
To: Michael Ellerman
Cc: mmarek-AlSwsSmVLrQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
davej-rdkfGonbjUTCLXcRTR1eJlpr/1R2p/CL,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1426031386.20917.4.camel-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
On 03/10/2015 05:49 PM, Michael Ellerman wrote:
> On Tue, 2015-03-10 at 17:39 -0600, Shuah Khan wrote:
>> On 03/10/2015 05:36 PM, Michael Ellerman wrote:
>>> On Mon, 2015-03-09 at 16:49 -0600, Shuah Khan wrote:
>>>> On 03/09/2015 08:28 AM, Shuah Khan wrote:
>>>>> On 03/04/2015 03:19 AM, Michael Ellerman wrote:
>>>>>> The makefiles under tools/testing/selftests are not real kbuild
>>>>>> makefiles, they are regular stand alone makefiles. As such they *do*
>>>>>> want all the standard implicit rules and variables defined.
>>>>>>
>>>>>> So before calling those makefiles, filter -rR out of MAKEFLAGS.
>>>>>>
>>>>>> Without this not all the selftests are built correctly when called via
>>>>>> the top-level Makefile.
>>>>>>
>>>>>> Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
>>>>>
>>>>> Hi Michal,
>>>>>
>>>>> Could you please take this patch in your tree.
>>>>>
>>>>> Acked-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>>>>
>>>>
>>>> I am changing this to a Nack. This is not fully cooked.
>>>> I am seeing new failures on some tests.
>>>>
>>>> gcc: error: elf_x86_64: No such file or directory
>>>> gcc: error: unrecognized command line option ‘-m’
>>>
>>> I can't reproduce that here. In what way do you think it's related to this
>>> patch?
>>
>> I have just your patch on tops of linux 4.0-rc3 and ran
>> make kselftest and that's what I see.
>>
>> If you can fix this problem I can take your patch, otherwise,
>> I have to go with individual Makefiles fixes.
>
> OK I see it now, only happens on x86.
>
> It looks like it's coming in via kbuild. Though I can only see it being set in
> arch/x86/Makefile.um, and I don't know why that is being sourced. But it must
> be.
>
> So this is another symptom of running via the top-level Makefile rather than
> directly.
>
> I'll try and find a fix.
>
If you can fix it that is great. I don't see any need to change
existing Makefiles to delete explicit rules based on this change
though.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* Re: [PATCH 37/45] include/uapi/linux/socket.h: include sys/socket.h in userspace
From: Mikko Rapeli @ 2015-03-11 0:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3218094.36vl2gijCv@wuerfel>
On Tue, Feb 17, 2015 at 10:14:10AM +0100, Arnd Bergmann wrote:
> On Tuesday 17 February 2015 00:05:40 Mikko Rapeli wrote:
> > This libc header has sockaddr definition for userspace.
> > Fixes compilation errors like:
> > error: field ‘ifru_addr’ has incomplete type
> > struct sockaddr ifru_addr;
> >
> > Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
> > ---
> > include/uapi/linux/socket.h | 4 ++++
> > 1 file changed, 4 insertions(+)
>
> This looks wrong: where do you see a use of ifru_addr
> in uapi/linux/socket.h?
Indeed, this one seems completely wrong. Based on the test logs the
change should have gone to linux/if.h.
-Mikko
^ permalink raw reply
* Re: [PATCH] kbuild: Don't pass -rR to selftest makefiles
From: Michael Ellerman @ 2015-03-11 0:46 UTC (permalink / raw)
To: Shuah Khan
Cc: mmarek-AlSwsSmVLrQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
davej-rdkfGonbjUTCLXcRTR1eJlpr/1R2p/CL,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <54FF8DC4.6000900-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Tue, 2015-03-10 at 18:35 -0600, Shuah Khan wrote:
> On 03/10/2015 05:49 PM, Michael Ellerman wrote:
> > On Tue, 2015-03-10 at 17:39 -0600, Shuah Khan wrote:
> >> On 03/10/2015 05:36 PM, Michael Ellerman wrote:
> >>> On Mon, 2015-03-09 at 16:49 -0600, Shuah Khan wrote:
> >>>> On 03/09/2015 08:28 AM, Shuah Khan wrote:
> >>>>> On 03/04/2015 03:19 AM, Michael Ellerman wrote:
> >>>>>> The makefiles under tools/testing/selftests are not real kbuild
> >>>>>> makefiles, they are regular stand alone makefiles. As such they *do*
> >>>>>> want all the standard implicit rules and variables defined.
> >>>>>>
> >>>>>> So before calling those makefiles, filter -rR out of MAKEFLAGS.
> >>>>>>
> >>>>>> Without this not all the selftests are built correctly when called via
> >>>>>> the top-level Makefile.
> >>>>>>
> >>>>>> Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
> >>>>>
> >>>>> Hi Michal,
> >>>>>
> >>>>> Could you please take this patch in your tree.
> >>>>>
> >>>>> Acked-by: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> >>>>>
> >>>>
> >>>> I am changing this to a Nack. This is not fully cooked.
> >>>> I am seeing new failures on some tests.
> >>>>
> >>>> gcc: error: elf_x86_64: No such file or directory
> >>>> gcc: error: unrecognized command line option ‘-m’
> >>>
> >>> I can't reproduce that here. In what way do you think it's related to this
> >>> patch?
> >>
> >> I have just your patch on tops of linux 4.0-rc3 and ran
> >> make kselftest and that's what I see.
> >>
> >> If you can fix this problem I can take your patch, otherwise,
> >> I have to go with individual Makefiles fixes.
> >
> > OK I see it now, only happens on x86.
> >
> > It looks like it's coming in via kbuild. Though I can only see it being set in
> > arch/x86/Makefile.um, and I don't know why that is being sourced. But it must
> > be.
> >
> > So this is another symptom of running via the top-level Makefile rather than
> > directly.
> >
> > I'll try and find a fix.
>
> If you can fix it that is great. I don't see any need to change
> existing Makefiles to delete explicit rules based on this change
> though.
I do. The explicit rules are generally wrong in some way, ie. they use flags
inconsistently, or they don't use CROSS_COMPILE when they should.
There should be no need to have explicit rules for simple tests that just build
a binary from a .c file.
cheers
^ permalink raw reply
* Re: [PATCH 37/45] include/uapi/linux/socket.h: include sys/socket.h in userspace
From: Mikko Rapeli @ 2015-03-11 0:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150311003815.GC12550-dqH1CgrzRhOk/eJAJmRu5A@public.gmane.org>
On Wed, Mar 11, 2015 at 02:38:15AM +0200, Mikko Rapeli wrote:
> On Tue, Feb 17, 2015 at 10:14:10AM +0100, Arnd Bergmann wrote:
> > On Tuesday 17 February 2015 00:05:40 Mikko Rapeli wrote:
> > > This libc header has sockaddr definition for userspace.
> > > Fixes compilation errors like:
> > > error: field ‘ifru_addr’ has incomplete type
> > > struct sockaddr ifru_addr;
> > >
> > > Signed-off-by: Mikko Rapeli <mikko.rapeli-X3B1VOXEql0@public.gmane.org>
> > > ---
> > > include/uapi/linux/socket.h | 4 ++++
> > > 1 file changed, 4 insertions(+)
> >
> > This looks wrong: where do you see a use of ifru_addr
> > in uapi/linux/socket.h?
>
> Indeed, this one seems completely wrong. Based on the test logs the
> change should have gone to linux/if.h.
Hmm, turns out this was not so straight forward. If I drop this I get 20
more errors from headers which include linux/socket.h and expect sockaddr
to be defined which is not true since it comes from sys/socket.h.
One way to fix this for all linux/socket.h users is to include sys/socket.h
already in linux/socket.h. After this I get rid of all compile test errors from
missing sockaddr definitions except cases where headers fail to include even
linux/socket.h.
Other option would be to include sys/socket.h in all headers using sockaddr.
I would prefer to include sys/socket.h already in linux/socket.h but I will
improve the commit message with this detail.
-Mikko
^ permalink raw reply
* Re: [PATCH 41/45] include/uapi/sound/emu10k1.h: hide gpr_valid, tram_valid and code_valid in userspace
From: Mikko Rapeli @ 2015-03-11 1:22 UTC (permalink / raw)
To: Takashi Iwai
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jaroslav Kysela,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <s5h4mqlqch1.wl-tiwai-l3A5Bk7waGM@public.gmane.org>
On Tue, Feb 17, 2015 at 07:27:38AM +0100, Takashi Iwai wrote:
> At Tue, 17 Feb 2015 00:05:44 +0100,
> Mikko Rapeli wrote:
> >
> > The DECLARE_BITMAP macro is not available in userspace headers.
> > Fixes userspace compile error:
> > error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’
>
> It's nonsense. This results in an incompatible structure, thus ABI
> would be broken completely (actually this will break the compile of
> ld10k1).
None of the exported headers after 'make headers_install' have definition
of DECLARE_BITMAP macro. It is defined in include/linux/types.h which is
different from include/uapi/linux/types.h and missing this definition and
a few other things.
One option would be add DECLARE_BITMAP macro to include/uapi/linux/types.h
and add include/linux/bitops.h to uapi.
Thoughts?
-Mikko
^ permalink raw reply
* Re: [PATCH 43/45] include/uapi/linux/netfilter_bridge.h: include if.h
From: Mikko Rapeli @ 2015-03-11 1:49 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Linux Kernel Mailing List, Netfilter Developer Mailing List,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LSU.2.11.1502170101520.32748-G+YmpvGGOO3H9RFtKMg/Ng@public.gmane.org>
On Tue, Feb 17, 2015 at 01:02:50AM +0100, Jan Engelhardt wrote:
> On Tuesday 2015-02-17 00:05, Mikko Rapeli wrote:
>
> >Fixes userspace compilation errors like:
> >
> >error: field ‘in’ has incomplete type
> >struct in_addr in;
> >
> >+#include <linux/if.h>
>
> Patch 36/45 included linux/in.h instead of linux/if.h for addressing "in has incomplete
> type". Should this be used here too?
It could, yes. It seems I cut some corners since this was hiding behind it:
In file included from ./linux/netfilter_bridge.h:11:0,
from ./linux/netfilter_bridge.c:1:
./linux/if_pppox.h:42:11: error: ‘IFNAMSIZ’ undeclared here (not in a function)
char dev[IFNAMSIZ]; /* Local device to use */
I'll fix these.
-Mikko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox