Re: CVS commit: src/sys/arch/news68k/conf

[Andrius V <vezhlys%gmail.com@localhost>]

On Sun, Oct 8, 2023 at 6:56 AM Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> wrote:
>
> > In this case maybe I should remove all FPSP references (vectors.S,
> > locore.S, Makefile.news68k (MD_LIBS={FPSP})?
>
> IMO we don't have to keep strict consistencies or buildabilities of
> options but rather should consider readabilities and maintainabilities.
>
> - options FPSP in a config file is not necessary for users on news68k
>   (unless some users build own 040/060 upgrade mod like x68k)

Yes, that's understandable and true. However, if someone would have a
mod, he would need to understand why FPSP build fails in the first
place.
I just wanted to avoid confusion, that code has ifdef blocks, but
there's no way to build it.

> - #ifdef FPSP (and other m68k specific options) blocks in common
>   sources might help to check diffs from other m68k ports

I was changing news68k specific code, thus wasn't treating them as
common.  But I understand the point.
I can return FPSP block in vectors.s, if that helps with readability
and maintainability.
However, those copy pasted common files usually diverge between ports
(from what I've seen),
makes it difficult to understand what is still common and what is the
"latest" code at times (likely not in this case).

>  - In the perfect world, we should have a common m68k/locore.s etc.
>    and move port specific blocks into locore_machdep.s like mips,
>    but m68k CPUs are too flexible and all m68k ports have too many
>    historical difficulties to refactor them

I admit I went a bit impatient this time without waiting for the
proper answer. I am OK to settle with the best option in the context,
either revert everything to original state, keep partial changes or
leave current state. Sorry for this.


>
> I don't mind your changes in this case, but it's appreciated
> to ask design considerations before changes, as you did for mmeye.
>
> Thanks,
> ---
> Izumi Tsutsui