Re: [PATCH RFC V3 6/9] x86/entry: Pass irqentry_state_t by reference
From: Ira Weiny
Date: Tue Oct 20 2020 - 10:10:32 EST
On Mon, Oct 19, 2020 at 11:12:44PM +0200, Thomas Gleixner wrote:
> On Mon, Oct 19 2020 at 13:26, Ira Weiny wrote:
> > On Mon, Oct 19, 2020 at 11:32:50AM +0200, Thomas Gleixner wrote:
> > Sorry, let me clarify. After this patch we have.
> >
> > typedef union irqentry_state {
> > bool exit_rcu;
> > bool lockdep;
> > } irqentry_state_t;
> >
> > Which reflects the mutual exclusion of the 2 variables.
>
> Huch? From the patch I gave you:
>
> #ifndef irqentry_state
> typedef struct irqentry_state {
> bool exit_rcu;
> + bool lockdep;
> } irqentry_state_t;
> #endif
>
> How is that a union?
I was proposing to make it a union.
>
> > But then when the pkrs stuff is added the union changes back to a structure and
> > looks like this.
>
> So you want:
>
> 1) Move stuff to struct irqentry_state (my patch)
>
> 2) Change it to a union and pass it as pointer at the same time
No, I would have made it a union in your patch.
Pass by reference would remain largely the same.
>
> 3) Change it back to struct to add PKRS
Yes. :-/
>
> > Is that clear?
>
> What's clear is that the above is nonsense. We can just do
>
> #ifndef irqentry_state
> typedef struct irqentry_state {
> union {
> bool exit_rcu;
> bool lockdep;
> };
> } irqentry_state_t;
> #endif
>
> right in the patch which I gave you. Because that actually makes sense.
Ok I'm very sorry. I was thinking that having a struct containing nothing but
an anonymous union would be unacceptable as a stand alone item in your patch.
In my experience other maintainers would have rejected such a change and
would have asked; 'why not just make it a union'?
I'm very happy skipping the gymnastics on individual patches in favor of making
the whole series work out in the end.
Thank you for your help again. :-)
Ira