Hiya Ben,

On Fri, 16 Feb 2001, Ben Harris wrote:
> >1b) allow multiple memory freelists to allow DMA/non-DMA division etc.
>
> >From my looking at it, it looks like the right way to handle this is to move
> the calls to uvm_page_physload() from pmap_bootstrap() to initarm(), so that
> the bootconfig structure isn't needed there.  If the pmap needs to know the
> physical memory layout, it can get it back from UVM.

Sounds like a very reasonable plan ... was part of my idea too ... I'm
also thinking of leaving the memory classification over to the bootloader.
In this way the kernels produced are more generic and can be booted under
more platforms by default ... the memory layout stuff is a bit too trivial
to need multiple compiled kernels.

> >3) merge podulebus code so arm32 and arm26 can use the same podulebus code
> >   -> if posible, move shared code to ../sys/dev/podulebus
>
> Once I've got a Risc PC, I'll work on this myself.

Thanks.... dispite other comments on this I think that moving the actual
podules etc to sys/dev/podules or something like that is a good idea
instead of putting it in sys/arch/arm because allthough its hard to find
other machines using podules outside the ARM community, its not a
processor thingy and both the archimedes, riscpc, rc7500? and imago use
them too. i.e. both arm26 and arm32 but not processor related. That way we
can keep sys/arch/arm really only for processor(+build in pheriphals?)

> >4) big one? : implementing wscons for RiscPC/rc7500
> >   -> cleans vidc directory and attachments too
>
> It might be possible to share some of this with arm26, too.

Yeah I was thinking about that too... esp. looking at the structure;
sounds pretty straitforward to couple a wscons ... is it really just a
ioctl interface that needs to be ok ?

It will sure clean out the vidc directory .... pity of the current vidc
console core really ... but i hope to get the wscons as fast as posible
using the VIDC's ability to hardware scroll, if nessisary MD dependent
screen move stuff.

Cheers,
Reinoud