Re: CVS commit: src/sys/arch/sparc

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

christos@ wrote:

> On Jul 31,  8:51pm, tsutsui%ceres.dti.ne.jp@localhost (Izumi Tsutsui) wrote:
> -- Subject: Re: CVS commit: src/sys/arch/sparc
> 
> | christos@ wrote:
> | 
> | Why don't you guys (as core? or individual developer?) post
> | an announcement that mentions benefit of -fno-common and
> | ask Tier II users to fix possible fallout, before putting
> | random MD fixes that would cause annoying silent hangs?
> 
> I can say the same for the port-masters who leave their ports
> broken for days.

I agree you can blame port masters if they leave their ports broken
more than *weeks*.

But tier II ports are not primary even for their users and
few people check status everyday.
No chance to notice breakage without heads up about MI changes.

If you claim port-masters must check buildable state *everyday*
against all MI changes without review or announcement, I'll resign
from all maintainership.

> But the benefits of -fno-common are pretty
> obvious: mistakes like having char *foo in one file and int foo in
> another, now will cause a build failure.

Ok, but why should it be defined in MI sys/conf/Makefile.kern.inc?

Isn't it enought to define it per port (only tier I ports for example),
or per kernel config file for debug purpose?

> | For sparc, the correct place seems in sparc/autoconf.c:bootstrap().
> | For sun2 it's sun2/locore2.c:_bootstrap().
> | Most other m68k ports foo_init() for pre-main initialization.
> 
> It would be nice if the individual port-masters would proactively
> check their ports so that they would remain buildable, and people
> who have cross-port knowledge like you, would work to harmonize
> these disparate and undocumented interfaces.

It would be nice if you guys asked proper persons to fix their ports
before you did try it yourself, so you don't have to check undocumented
MD kludges.

IMO "buildable but non-bootable state" is worse than non buildable.
It just hides actual problems and makes late debug harder.

---
Izumi Tsutsui