On Wed, Aug 15, 2012 at 11:37 AM, McClintock Matthew-B29882
[off-list ref] wrote:

On Tue, Jul 24, 2012 at 8:40 AM, Burton, Ross [off-list ref] wrote:

quoted

On 24 July 2012 14:27, Chris Larson [off-list ref] wrote:

quoted

On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan [off-list ref] wrote:

quoted

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

For what it's worth, we applied this in our layer and things do seem
to work fine with this applied. It was either this or what we did
before (reverted the switch to kmod-native and retained
module-init-tools-cross), as we require CentOS5/RHEL5 support still.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics