[lkml]   [2022]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] MIPS: undefine and redefine cpu_has_fpu when it is overrided
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


 \ /
  Last update: 2022-04-30 17:41    [W:0.046 / U:3.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site