Subject: Re: pmap and kvm nonsense
To: Charles M. Hannum <mycroft@gnu.ai.mit.edu>
From: Rob Healey <rhealey@kas.helios.mn.org>
List: current-users
Date: 09/18/1994 11:05:26
> 1) You should eliminate `struct pte' and `struct ste', and instead use
> `pt_entry_t' and `st_entry_t', typedef'd to the appropriate types
> (i.e. int or u_int; I don't care which).  You can use masks and shifts
> to extract and insert values.
> 
> 2) I want to see the use of `cpu040' die, especially as it's used now.
> The hack for SEGSHIFT, in particular, is just sick.  I can't think of
> any reason to not have a real `mmutype' variable like the hp300 port
> does.
> 
> 3) It would be nice if the pmaps for the various m68k ports were
> merged.
> 
> 4) The Amiga port will find that libkvm doesn't compile in the main
> branch of the CVS tree until it does at least part of #1.
> 
	#4 is a particularly distasteful tactic. Minimally, the changes
	to libkvm should have been coordinated with the m68k maintainers
	so that situations like #4 wouldn't happen.

	If this sort of stunt was pulled with the x86 port you would have
	been strung up without question!

	Deliberately breaking a port to "force" them to do something a
	certain way is a pretty low tactic...

	Hopefully next time things can be coordinated with the m68k
	core before making yet ANOTHER port breaking change.

	Is this a trend or something? First ptrace() is broken for m68k
	ports then libkvm, a MUCH more important function, is changed in
	a matter that makes the Amiga port seriously broken.

	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?

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

	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"...

		-Rob