Re: [PATCH v2] kmod: Handle undefined O_CLOEXEC

From: Chris Larson <clarson@kergoth.com>
To: McClintock Matthew-B29882 <B29882@freescale.com>,
	 Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v2] kmod: Handle undefined O_CLOEXEC
Date: Wed, 15 Aug 2012 12:10:51 -0700	[thread overview]
Message-ID: <CABcZANkfFMgTxeQWzpKe2d2NqhMYaz27q-dnfW5m7-BJO2yygQ@mail.gmail.com> (raw)
In-Reply-To: <CAEsOVNcVB5zp7rhN4LP7ANx3hDq51kFQt_0L=O5=YLU6Qp_D-Q@mail.gmail.com>

On Wed, Aug 15, 2012 at 11:37 AM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Tue, Jul 24, 2012 at 8:40 AM, Burton, Ross <ross.burton@intel.com> wrote:
>> On 24 July 2012 14:27, Chris Larson <clarson@kergoth.com> wrote:
>>> On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan <radu.moisan@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).

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