#Class-like inheritance problems in UVM-style virtual memory management

11 messages · Page 1 of 1 (latest)

carmine thorn
#

I'm looking for some advice on how to organize my structs and traits here:

I'm working on implementing a UVM-style (https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf) virtual memory management system in my own hobby OS kernel. It, however, uses class-style inheritance (written in this case in C, though this should also work with C++) to achieve one important function: The interface to a memory object.

Let me explain. A memory object is something that can be mapped into virtual memory (often a file window). This interface has functions to get, mark dirty, and put (drop reference to) pages within the object. I want to use a page cache to implement this part of the interface.

Here's the problem: The PageCache needs to call something underlying to actually interact with the backing store. However, I want my Arc<VNode> (virtual inode; file) to implement MemoryObject. It would be most fitting (were this C or C++) to also use class-style inheritance to fix this. But this is Rust.

I have three potential alternate solutions, each of which suboptimal for different reasons:

  1. Give the PageCache a *const dyn Pager pointing to the VNode (requires more unsafe)
  2. Make every call to the PageCache accept a &dyn Pager (not clean in terms of ownership)
  3. Use several additional traits to use a PageCache to implement MemoryObject on object that also implement Pager (need a trait just to get the struct PageCache to use)

What are your thoughts?

#

Class-like inheritance problems in UVM-style virtual memory management

carmine thorn
bitter idol
#

Well doing anything that is OOP in rust is likely to be a pain, if I were to give my 2 cents tho you could also just store the "parents" as fields within the struct and simply acces those fields

For any overwritable behaviour simply implementing your own fields should work

#

You can also use impl Borrow<Parent> for Child if that helps ur usecase

#

As it would allow for a simple impl Borrow<Parent> interface for accesing the Parent type along side any Child type that may implement that trait

#

Tho considering the "OOP" style code is made in C, it should be relatively easy compared to true OOP to translate that code into C styled Rust if worst comes to worst

#

Bdw, if you do want to go with option 2 you can also try doing something with Box<dyn Paher> as that will allow for clear and sound ownership

#

Or an Arc/Rc or some other smart pointer

cunning pulsar
carmine thorn