> 	Who made whom god such that cpu040 or any other internal mechanism
> 	is unfit? Maybe the '040 ports have more important things to do
> 	or get working at this time? So we just go ahead and seriously
> 	break things for them? Like they don't have enough work to do
> 	as it is?

'cpu040' was deemed 'unfit' a long, long time ago, earlier than May.

> 	Maybe the m68k core was told before hand but from the wording it
> 	doesn't seem so.

They were told to change it _months_ ago, and that eventually support
for it was going to go away.

> 	I send this to a wider audiance so if ports other than m68k start
> 	to see stuff like this the trend can be followed.
> 
> 	The m68k ports have enough problems to deal with right now, most
> 	notably the broken ptrace() code, the last thing they needed was
> 	to have someone singlehandedly decide for them that their ports
> 	were done "wrong"...

Umm, this has nothing to do with the ptrace() code.  Additionally, you
apparently haven't noticed our explanations of why we changed ptrace:
we had little choice in the matter.

If you'll recall, NetBSD-current (i.e. that on the trunk of the tree)
isn't guaranteed to compile on any architecture on any day.  It's not
like this is going into the release branch.

And if you think _this_ is bad, i've got about 40k lines of diffs
(~1M in total size) that aregoing into the tree after the release is
out the door, that's going to break _every_ port (and some of them
quite seriously), and will completely hose the SysV ipc code (because
of its crappy interfaces).  That's the way NetBSD-current works: you
make a global change, and it takes a bit of time to get everything
completely sorted out and working again.


chris