[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55BA2B91.5070107@windriver.com>
Date: Thu, 30 Jul 2015 09:50:09 -0400
From: Paul Gortmaker <paul.gortmaker@...driver.com>
To: David Herrmann <dh.herrmann@...il.com>
CC: David Herrmann <dh.herrmann@...glemail.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Daniel Mack <daniel@...que.org>,
Djalal Harouni <tixxdz@...ndz.org>,
<linux-mips@...ux-mips.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>
Subject: Re: samples/kdbus/kdbus-workers.c and cross compiling MIPS
On 2015-07-29 12:31 PM, David Herrmann wrote:
> Hi
>
> On Wed, Jul 29, 2015 at 6:19 PM, Paul Gortmaker
> <paul.gortmaker@...driver.com> wrote:
>> Hi David,
>>
>> Does it make sense to build this sample when cross compiling?
>>
>> The reason I ask is that it has been breaking the linux-next build of
>> allmodconfig for a while now, with:
>>
>> HOSTCC samples/kdbus/kdbus-workers
>> samples/kdbus/kdbus-workers.c: In function ‘prime_new’:
>> samples/kdbus/kdbus-workers.c:934:18: error: ‘__NR_memfd_create’ undeclared (first use in this function)
>> p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC);
>> ^
>> samples/kdbus/kdbus-workers.c:934:18: note: each undeclared identifier is reported only once for each function it appears in
>> scripts/Makefile.host:91: recipe for target 'samples/kdbus/kdbus-workers' failed
>> make[2]: *** [samples/kdbus/kdbus-workers] Error 1
>
> mips does have this syscall, so I assume the problem is out-of-date
> kernel headers. You can fix this by running:
>
> $ make headers_install
No, let me try and clarify. Please note the emphasis on cross compiling
and automated build coverage, i.e. there is no place for manual steps.
On kernel.org there are x86 host binaries that allow a person to build
a kernel for nearly every arch:
https://www.kernel.org/pub/tools/crosstool/
These exist so developers doing treewide changes can test that their
work does not break s390 or powerpc, or ....
However, in the interest of simplicity, these compilers are created
such that they can build the self contained kernel only. They do not
have all the headers and libc stuff needed to compile and link an
actual s390 or powerpc userspace -- for that you'd need a full sysroot.
And this is fine for 99.9% of stuff. And it was fine for the automated
builds of the linux-next tree for the MIPS architecture and the
allmodconfig target prior to the kdbus inclusion.
And I really don't need a s390 or powerpc sample program, hence why
I suggested we skip it when cross compiling, just like the other
commits I quoted.
The implicit rule with linux-next (and linux in general) is essentially
"You broke it, you get to fix it." So either skipping this in the
Makefile when cross compiling, or working with Michael and the linux-next
team to have their builders somehow skip it needs to be done by the
kdbus team.
Thanks,
Paul.
--
>
> This will put the sanitized headers in your local kernel tree
> "./usr/". This is preferred over "/usr" as include path for the kernel
> examples, hence, everything should work fine then.
>
> The kernel samples/ directory is explicitly used for example programs
> for the kernel. Hence, I think it is quite fine to use new kernel
> features. Same applies to the selftests.
>
> I'd be fine making kdbus-workers a no-op program if __NR_memfd_create
> is not defined. But I'm not really sure that fixes real problems. I
> mean, new samples and selftests will be added by other subsystems and
> those might as well require new kernel headers.
>
> Thanks
> David
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists