[OE-core] Syscall backporting and linux-libc-headers

[Bruce Ashfield]

On 12-03-23 08:35 AM, Richard Purdie wrote:
> On Thu, 2012-03-22 at 11:44 -0400, Bruce Ashfield wrote:
>> On 12-03-22 11:12 AM, Koen Kooi wrote:
>>>
>>> Op 22 mrt. 2012, om 15:49 heeft Richard Purdie het volgende geschreven:
>>>
>>>> On Thu, 2012-03-22 at 13:22 +0100, Koen Kooi wrote:
>>>>> In my never ending quest to get consolekit/polkit/etc working properly
>>>>> I've found that CONFIG_AUDITSYSCALL is really usefull (it's usefull in
>>>>> other contexts as well, but that's outside the oe-core set of
>>>>> recipes). It has the following problem:
>>>>>
>>>>> config AUDITSYSCALL
>>>>>          bool "Enable system-call auditing support"
>>>>>          depends on AUDIT&&   (X86 || PPC || S390 || IA64 || UML ||
>>>>> SPARC64 || SUPERH)
>>>>>
>>>>> No MIPS or ARM support. There recently was a pull request from Al Viro
>>>>> to get at least ARM support into mainline, but I'm not sure what
>>>>> happened to that. Anyway, I backported the ARM patch to 3.0 and 3.2,
>>>>> but to make it usefull I'd need to patch linux-libc-headers and bump
>>>>> PR on virtual/libc.
>>>>>
>>>>> What's the OE-core position on backporting syscalls to
>>>>> linux-libc-headers?
>>>>
>>>> Why can't we just increase the linux-libc-headers version?
>>
>> Sorry for the slow reply, I missed the original and was wrapped
>> up in some debugging.
>>
>>>
>>> In this case that would be perfectly fine. And bump PR in virtual/libc of course :)
>>
>> I was just about to do this. Just a day or so ago, I noticed that
>> the version had lagged (again) and needed to be bumped. I'm all
>> for this as well, as long as there's a graceful fallback of ENOSYS
>> there's no real harm to older kernels.
>>
>> Richard: an to you on this one .. is it too late to do this for
>> the various stabilization points ?
>
> I'm a bit jittery on this. If I have the patch today and it doesn't
> break anything it might make it in..

I've made the changes here and am watching some builds churn away,
so far so good.

But I realized that this won't solve the issue that prompted Koen's
original email. The audit syscall for ARM. When it does merge, we'll
be able to bump past the version that contains it, and then make it
universally available in the right version of the libc-headers
package.

Bumping to 3.2 won't get us there, so if we'd rather not do this
right now. I'm ok going with the 3.1 headers that we've been using
all along.

I can still send the patch later today and leave the decision up
to you, but thought I should make another comment.

Cheers,

Bruce



>
>>>> Presumably
>>>> someone running a kernel without the patches won't see any issue, the
>>>> syscall just won't be present and software will fall back?
>>>
>>> Exactly
>>
>> +1 (I read this after typing my response).
>>
>>>
>>>> I think the big concern would be deviating from mainline as its not so
>>>> much a backport as a divergence at this point (and this is why we can't
>>>> just upgrade)?
>>>
>>> Speaking of divergence, what is the point of having linux-libc-headers-yocto_git.bb ?
>>
>> Very little. It was originally used to export exactly the headers
>> as were present in the yocto kernel tree, but Richard and I since
>> agreed that tgz based libc-headers where faster and good enough.
>>
>> We can move it to the yocto layers for use by anyone that really needs
>> this 1:1 mapping of kernel tree to headers in the system.
>>
>> And a second: .. is it too late to do this for stabilization points ?
>
> No, I'll take that one since its a removal on something that is unused.
>
> Cheers,
>
> Richard
>