drochner@zel459.zel.kfa-juelich.de wrote:

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

At this stage, I disagree with this ("easily be called by a macro").  I
can't see a single place where I can say "#define bzero(a, b) memset(a,
0, b)" that will affect all of libsa/libkern.  Proof the contrary gladly
accepted :-)

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

We do have filesystem reading code that fits comfortably in the current
bootblocks, with the exception of symlink handling.  Compare that
with the blocklist concept, where a simple dump/restore of the root
filesystem will result in a system that probably won't boot without
having to remember to run a command afterwoods.

> 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?

How were you doing the network IO?  Prom routines or a stand-alone
device driver?

Simon.