>Uses of memset(buf, val, len) with val!=0 are rare or not present
>at all. The whole memset() API is crap imho because it is limited
>to bytewise operation. This is not userland, so we don't have to
>obey POSIX or whatever, so I'd vote to keep the more efficient bzero()
>in libsa.

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.


>As someone (cgd?) said: This is a battle you can only lose.
>You won't be able to implement nice features, and with every
>libsa or compiler change the trouble begins again. Or perhaps
>we'll get a working LFS one day, and want to boot from it...

But the pmax really needs `clean' two-stage bootblocks in any case, to
support netbooting.  First because the PROMs are buggy and cant boot
install-sized kernels, second to support ELF kernels (rather than
ECOFF), third to load an ELF kernel via NFS rather than TFTP (to make
the name of the kernel available).


Given all that, a first-stage bootblock which lives in the ~8k
reserved for bootblocks, and a second-stage ECOFF secondary boot with
the "nice" stuff, which just loads the ECOFF variant, is the obvious cutpoint.

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


>I consider the bootblock installation by "disklabel" worse
>than a port-specific "installboot". Dealing with the port specifics
>within "disklabel" leads to an "#ifdef" mess, and cross-platform
>support would be easier too if "disklabel" would only do what it
>is called after: editing disklabels.

Both are unclean, but I dont see where your argument holds water.
Where to find the BSD label is itself machine-dependent.
and if your idea of `cross-platform support' includes installing
bootblock code onto anothe platform's disk, then its a wash.