racin at free.fr
Sun Jan 15 13:06:06 EST 2006
"Jonathan S. Shapiro" <shap at eros-os.org> writes:
> COLORED PINSETS
> One important use of PinSets is for drivers, and in that case it is not
> enough to pin the page -- you need to pin the page at an address that
> the DMA engine can reach. This may mean pinning within a restricted
> range, and it may introduce modular placement limits.
> Extending pinsets to handle this is straightforward. The PinSet is
> augmented to have a base and bound physical address, and the insert()
> operation is augmented to allow specification of a modular address
> pinset.insert(aspace cap, pg offset, constraint)
> This leads to some new possible failures in the insert() operation:
> 1. "page cannot be pinned within constraint" This fault means that
> no frames are available within the specified base/bound.
> In the intended usage, this means that your frame scheduler has
> messed up rather badly.
> 2. "page pin conflict" The page is already pinned.
> 3. "modular constraint failed" There was sufficient space and resource
> to perform the pin, but the requested modular constraint could not
> be met.
> 4. "limit reached" (as before)
What would be the form of the constraint? Would it be a simple couple
(address_min, adress_max), or a more complicated scheme?
Neal originally wanted to express constraints on physical memory
location by using two words :
- bits in the first word will indicate bits which have to be on in the
address of the physical memory eventually choosen
- bits on in the second word will indicate bits which have to be off in
the address of the physical memory eventually choosen
This lead me to write an algorithm (a variation on the buddy system
that allows to take these constraints into account).
You can see a preliminary description of it here
I hope this can be of interest for you.
Are you still interrested by such forms of constraints, or do you have
decided for simpler schemes?
More information about the coyotos-dev