caller to pass an optional 3rd argument, which is the previous level
PTE corresponding the virtual address. If this argument is non-NULL,
the table walk otherwise necessary will be bypassed.
enough to use as a console on my DEC 3000/400 (connected to a VT-520
terminal).
XXX The MI SCC driver needs serious changes to handle platforms which
have muliple SCC attachments (e.g. the Alpha port, which has an ioasic
attachment for TurboChannel systems and a gbus attachment for TurboLaser
systems).
XXX The MI SCC driver also needs changes to deal with the wacky (to put
it mildly) way the chips are wired up on the ioasic (on both TC Alphas
and DECstations). These are going to come along later.
Major change is that page table page management has been completely
rewritten. Page tables are now accessed via K0SEG (no more KVA space
wasted on user page tables), and a much larger user address space is
supported.
Many thanks to Chris Demetriou and Ross Harvey for helpful insight and
debugging assistance.
- Make pv_table an array of struct pv_head's, which contain LIST_HEADs
for the pv_entry's, as well as page attributes (mod, ref, ptpage).
- Use <sys/queue.h> to manipulate pv_entry lists.
- Fix several obvious bugs in pmap_collect_pv().
- Use K0SEG to access pv_page's.
- Clean up pmap_bootstrap() some, and make a slight change to how the
PROM mappings are saved.
- Give each pmap its own level 1 page table, rather than sharing a global
level 1 page table. This will eventually allow for Very Large user
address spaces.
- Keep a list of all pmaps, so that when kernel level 2 page tables are
allocated, all level 1 tables may be updated.
- Add a couple of functions for allocating and freeing page table pages.
- Add a few comments about ASN allocation.
These changes also recover memory that is located before the kernel in
the first system software segment on systems which do not use the PROM
for console I/O. Written by Chris Demetriou and myself.
knowledge) earlier, and gather all information needed earlier. Mark the
init code carefully re: when it can print stuff out, when it can expect
the firmware to stop working, etc. Be more careful about using the PROM
console and other PROM facilities, and hint that in the future all use
of firmware/boot program callbacks by the kernel should go away (since
the world may not be mapped the way the firmware/boot program wants!).
thorpej