Re: [PATCH v2] MIPS: undefine and redefine cpu_has_fpu when it is overrided

[Maciej W. Rozycki]

On Sat, 30 Apr 2022, Stephen Zhang wrote:

> >  Additionally I've thought of adding something like:
> >
> > #if cpu_has_fpu
> > # undef cpu_has_fpu
> > #endif
> >
> > or maybe even:
> >
> > #if cpu_has_fpu
> > # error "Forcing `cpu_has_fpu' to non-zero is not supported"
> > #endif
> >
> > to arch/mips/include/asm/cpu-features.h, but maybe that's an overkill.
> 
> Yeah, but why do you think that's an overkill? There is a great chance
> people will ignore the note of 'cpu_has_fpu', and it did happen. When
> that happens, there should exist a way to point out  or fix that.

 Maybe it's the language, but my intent has been to express my uncertainty 
here rather than asserting that indeed it is an overkill.

 People do make mistakes from time to time, both code writers and 
reviewers do.  It's not clear to me where to draw the line for safety 
checks though.

 Here `cpu_has_fpu' is a bit unusual in that unlike with the other feature 
override macros we don't want it to expand to a non-zero constant.  The 
comment didn't work twice, though I suspect both cpu-feature-overrides.h 
files may have been written before the comment went in (I'm fairly sure 
the IP30 port lived outside the tree for a while).  But I have only added 
the comment in the first place when I tripped over the `nofpu' option not 
working for the machine I needed to run FPU emulator verification with, 
and several platforms were fixed alongside.

 Given these circumstances it probably makes sense to have such a safety 
check after all.

> > I prefer just removing the #defines from ip27/ip30 cpu-feasture-overrides.h.
> > Or isn't that enough for fixing the problem ?
> >
> > Thomas.
> 
> So maybe that's  why I don't think just removing the #defines from
> ip27/ip30 cpu-feasture-overrides.h. is enough for fixing the problem.

 Well, that *is* the fix for the problem at hand, as this macro is not 
supposed to be defined such as to expand to a non-zero constant.

 Adding a safety check would be a separate improvement.  Please feel free 
to submit one.

 We need to keep fixes and improvements as separate changes.  For one 
fixes can be candidates for backporting while improvements are never 
backported; cf. Documentation/process/stable-kernel-rules.rst.

 I hope this clears your concerns.  Let me know if you have further 
questions.

  Maciej