Hi,

eeh@netbsd.org wrote:
> | > return sysctl_rdint(oldp, oldlenp, newp, CACHELINESIZE);
> 
> That needs to be changed too.  The cache line size is not
> necessarily fixed.

Well, we don't currently support (officially) any ppc cpu that has a
cache line size different from 32.

That said, AFAICT, the only ppc cpus that currently exist with line
sizes different from 32 are the embedded ones and the 64 bit ones.
Now I may be totally out of my mind, but AFAICT both of those are in
need of different kernels anyway.

At least for now, I don't see a need to support non-fixed cache line
sizes in the kernel.

If this changes, CACHELINESIZE could be easily changed to some
variable, initialized early during startup, and used similar to what
is done in userland.

And from the keyboard of mjl@emsi.priv.at:
> |   So I am soliciting ideas and/or fixes to the problems mentioned
> | here:
> |
> |   - dependency on assym.h

The correct fix is to protect the cpu.h include file in a way to be
able to include this into asm code, i.e. to "#ifndef _LOCORE" out any
structure definitions and the like, which the assembler would barf on.

> |   - use of libkern by non-kernel (but with no working sysctl either,
> |     eg. bootloader)

Would be fixed by the above.

The exception being the change of CACHELINESIZE to a variable.  This
variable would have to be declared external in cpu.h (with appropriate
alternative code for including this file into asm), and it would have
to be initialized during startup of the standalone utility, just as in
the kernel case.

> |   - how to actually and correctly get at the cache line size
> |     in kernel (do we have to have that dynamic too? if so, I
> |     fear the infrastructure for that is not in yet place, see
> |     the snipped above for the sysctl).
> 
> Yes, the in-kernel cache line size needs to be dynamic.

See above.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     Wolfgang Solfrank, TooLs GmbH 	+49-228-985800