[OE-core] [PATCH v2] kmod: Handle undefined O_CLOEXEC

[McClintock Matthew-B29882]

On Tue, Jul 24, 2012 at 8:40 AM, Burton, Ross <ross.burton at intel.com> wrote:
> On 24 July 2012 14:27, Chris Larson <clarson at kergoth.com> wrote:
>> On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan <radu.moisan at intel.com> wrote:
>>> I have not tested on CentOS 5.8 if the applications are not broken in some
>>> way, but that's not in the scope of this patch. If something does indeed
>>> break, then a totally different patch is required, targeting a backport of
>>> kmod for kernel older than 2.6.23.
>>
>> Personally, I'd rather see the build fail than have the tools behave
>> incorrectly in some inexplicable way. If you haven't tested it, the
>> patch shouldn't go in.
>
> I was curious...
>
> There are two commits in kmod where the cloexec changes were made:
>
> http://git.profusion.mobi/cgit.cgi/kmod.git/log/?qt=grep&q=cloexec
>
> The changes were a simple addition of the O_CLOEXEC flag, so this
> patch is simply the union of those two commits.  A release of kmod
> that doesn't require O_CLOEXEC has the same behaviour as this patch.
> The problem O_CLOEXEC is solving isn't possible to solve cleanly
> without it.  Using an older version of kmod instead of patching kmod
> to work on older systems would result in more bugs and less features
> for no win.

Was there any conclusion on this? I'm seeing the same problems. This
would only effect kmod-native (unless the target was using the older
stuff as well which is uncommon at this point).

Looking the commit that adds this as a dep:

commit f22cf1bedf2aa7fb41f98d6165401eb8a8bad17d
Author: Khem Raj <raj.khem at gmail.com>
Date:   Tue Jan 31 00:35:02 2012 -0800

    image.bbclass,kernel.bbclass: Use kmod-native instead of
module-init-tools-cross

We are just using depmod from this recipe for the kernel build, which
is a non-threaded user of this libraries built within kmod - therefore
we should not encounter any issues [1](after reading what O_CLOEXEC
does) with this patch except that it should only be applied to -native
builds. Also, if issues do present themselves they will be during the
build and not later at runtime so we can identify any issues that
arise.

So in summary, the patch should (IMO) be:

SRC_URI_append_virtclass-native =
"file://Handle-unsupported-close-on-exec-flag.patch"

Thoughts?

[1] http://lwn.net/Articles/249006/

-M