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

ok. patch pending now. I'm doing extra builds here.

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

ok. I'll get this one fired out as well.

Bruce

>
> Cheers,
>
> Richard
>
x