On 5/5/22 16:18, Joseph Salisbury wrote:
> The real-time kernel build failure can be resolved by reverting commit
> b50854eca0e0. The failure seems to be due to the removal of an include
> of xstate.h from pkru.h and caused spinlock_t to not be defined. The
> commit would only be reverted for the real-time kernel and not any other
> kernels. I wanted to see if reverting the commit is the proper
> approach, or if cherry-picking additional commits might be a better
> solution in preparation for additional changes that might be coming in
> the future?
>
> Any suggestions would be greatly appreciated.
I thought you distro folks were the franenkernel experts. :)
But, seriously... This isn't rocket science. Just look at the pkru.h
in your tree and figure out what includes it needs. If it needs FPU
gunk, include the FPU header. If you get a compile error for spinlock_t
... well ... find the code using spinlock_t and make sure it includes
spinlock.h.
On 5/5/22 19:35, Dave Hansen wrote:
> On 5/5/22 16:18, Joseph Salisbury wrote:
>> The real-time kernel build failure can be resolved by reverting commit
>> b50854eca0e0. The failure seems to be due to the removal of an include
>> of xstate.h from pkru.h and caused spinlock_t to not be defined. The
>> commit would only be reverted for the real-time kernel and not any other
>> kernels. I wanted to see if reverting the commit is the proper
>> approach, or if cherry-picking additional commits might be a better
>> solution in preparation for additional changes that might be coming in
>> the future?
>>
>> Any suggestions would be greatly appreciated.
> I thought you distro folks were the franenkernel experts. :)
>
> But, seriously... This isn't rocket science. Just look at the pkru.h
> in your tree and figure out what includes it needs. If it needs FPU
> gunk, include the FPU header. If you get a compile error for spinlock_t
> ... well ... find the code using spinlock_t and make sure it includes
> spinlock.h.
>
Thanks for the advice, Dave.
Your suggestion will probably be the easiest approach. I was just
trying to limit the amount of frankenkernel changes, since there are
already so many :-) It's always best to stay as close to mainline as
possible.