jonathan@DSG.Stanford.EDU said:
> Yes, I agree, but if we know val == 0 is the common case we can
> special-case it. Thats what the standalone memset() for mips does. 

OK, but then we still have effectively dead code in memset()
and pass dummy arguments ("0") to this function.
I'd say the mi libsa code should use bzero() to keep the information
that the memory has to be _zero_ filled. If a port chooses to
implement memset() only it can easily be called by a macro. The other
way wouldn't work (or only with nasty gcc-internal
__builtin_constant_p() or so).

> But the pmax really needs `clean' two-stage bootblocks in any case, to
> support netbooting.

I didn't speak against 2-stage booting - what I wanted to say
is that squeezing filesystem reading code into the first ~8k will
cause endless trouble. So a blocklist is the way to go. Whether
for the "final" boot stage or an intermediate stage, is another question.

I've played with a "netboot" stage a while ago btw. While it
did startup well and did BOOTP properly, it always failed to
receive ARP replies, so it couldn't load the kernel.
(on a '240) At the beginning I assumed timing issues - the reply
could be faster than the switch between send and receive, but
I've tried a number of hacks and did never see even one ARP
packet, so I gave up. Is it possible that the console eats
them up?

> We'll just have to agree to disagree over whetehr installboot-style
> bootblocks are ugly and nasty. ;)

Obviously...

> Where to find the BSD label is itself machine-dependent.

OK, didn't think of that. One could introduce a commandline
argument for "labelsector" however. (only needed for initial
installation)

best regards
Matthias