[EROS-Arch] Depend logic is machine dependent

[Charles Landau]

kern_Depend.cxx is in the machine-independent part of the code, but the
logic in it is somewhat machine-dependent, even among architectures with
an MMU that walks a tree of mapping tables. The problem is that
Depend_AddKey associates a key with a PTE (Page Table Entry) only. It
does not distinguish between table entries at different levels of the
mapping tree (they must be cast to PTE). This gives rise to two
problems:

(a) Table entries at different levels may need to be invalidated
differently. On one architecture I have seen, second level page table
entries had to point to a page table; an invalid second level page table
entry pointed to a page table with all invalid entries. For another
example, if fixRegs.MappingTable were invalidated with KERNPAGEDIR
rather than zero, it might simplify some code that checks for both zero
and KERNPAGEDIR in this field.

(b) PTE::CanMergeWith() may be different for table entries at different
levels. On the ARM for example, page tables are less than a page in size
and higher-level mapping tables are more than a page in size.

I also find it kludgy that the procedure requires the caller to pass the
allowMerge parameter, then calculates what it should be and complains if
different
(http://www.eros-os.org/eros-src/sys/kernel/kern_Depend.cxx#121). In
fact the value of allowMerge is a simple function of the level (true if
not top level).

One solution would be to store in the dependency database the level (2
bits probably suffice) and a pointer to the entry at that level, instead
of the "PTE" pointer.

Another solution is to say that table entries must occur in physical
pages with an object header that identifies their level (variants of
ObType::PtMappingPage). Actually, (pMappingPage->producerNdx ==
EROS_NODE_LGSIZE) seems to be an attempt at that. (Top level entries,
which occur in the Process structure, seem to be a special case; see
http://www.eros-os.org/eros-src/sys/kernel/kern_Depend.cxx#115 .)

Comments?