Syscall backporting and linux-libc-headers

Syscall backporting and linux-libc-headers

[Koen Kooi]

Hi,

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? 

regards,

Koen

Re: Syscall backporting and linux-libc-headers

[Richard Purdie]

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

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

CC'ing Bruce since I know he holds opinions on this kind of thing :)

Cheers,

Richard

Re: Syscall backporting and linux-libc-headers

[Koen Kooi]

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?

In this case that would be perfectly fine. And bump PR in virtual/libc of course :)

> 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

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

regards,

Koen

Re: Syscall backporting and linux-libc-headers

[Bruce Ashfield]

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 ?

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

Cheers,

Bruce

>
> regards,
>
> Koen

Re: Syscall backporting and linux-libc-headers

[Richard Purdie]

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

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

Re: 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

Re: 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
>