> >some (including me 8-) would argue that the hp300 should be converted
> >to use 8k page sizes for all of its binaries.  This would allow hp300
> >and other m68k ports' binaries to be completely interchangeable, with
> >no special hooks, etc.  It would cost (on average) 4k extra disk space
> >per binary, on hp300 systems.  That cost comes out to 2-3M, given an
> >average extra space per binary of 4k, and given between 500 and 750
> >binaries per system (the average, i'd say, at least looking at one of
> >the hp300's i've access to).
> 
> I think that the 4k page size should remain the default for the hp300,
> as far as what the kernel expects as it's `default' binary format.

a 4k MMU page size, of course.  it's worth noting that, of the m68k8k
ports, only _two_ (amiga and sun3) use an 8k MMU page size.  MMU page
size and linker page size have little to do with each other, except
that it's inefficient to be running binaries for which the linker page
size is less than your MMU page size.

you say something below that contradicts your latter statement, btw.

> 8k support should be probably be added to the kernel, as you say.  As
> an option.  Then it only stands to reason that the appropiate tools
> (gas, ld, etc.) should be whacked to be able to produce either 4k or
> 8k object files, depending on command line switches.

joy: that would add Yet Another Set of Options to ld, et al.  and it
would be a m68k-specific set.  "blech."

> There's nothing wrong with making the hp300 do 8k page binaries, so
> long as you can still exec 4k binaries, and the tools can still produce
> them.  I'd even say it'd be ok for the tools to produce 8k page-size
> object files by default.

Sure, keep compatiblity with 4k binaries as a compatibility option.
that's perfectly reasonable, but:
	1) why allow them to be generated in the future?  that seems
		an unnecessary feature, especially if 8k
		linker-page-size binares are "ok" to be the default,
	2) if you're going to produce 8k linker-page-size object files
		be default, why not make running them the default case,
		in the kernel?!  why slow down your default case?

The point is, if it's OK to produce 8k linker-page-size object files by
default, there seems little reason to keep support for 4k
linker-page-size bins around, _EXCEPT_ as a backward compatibility
option in the kernel.


The whole point of this is that i'd like to be able to ship exactly
_ONE_ set of binaries for all m68k ports, and have any m68k port be
able to generate those binaries.  that would be possible now, if:
	(1) the hp300 kernel was hacked to understand m68k8k binaries
	(2) the hp300 utils were changed to, by default, generate
		m68k8k binaries.

However, were one to make both of those changes, it would make more
sense to just change the hp300 port to do m68k8k binaries (i.e. 8k
linker page size binaries) by default, and keep m68k4k support around
as a compatibility option.



cgd