determine allocator page/frame provider API

[hawkw]

see https://github.com/hawkw/alarm/issues/17#issuecomment-359283405

[hawkw]

there exists some prior art: https://github.com/gz/rust-slabmalloc/blob/84fdb79f1f2305d39badd116546678f6b3784326/src/lib.rs#L56-L64

https://github.com/hawkw/sos-kernel/blob/cbe8107fe943643f1cb6d0fcafbd1ac141442fbd/sos_alloc/src/frame/mod.rs#L19-L31

https://github.com/phil-opp/blog_os/blob/3f4a4bf2e1d38427bcbfdd31a09f3b510d09be2b/src/memory/mod.rs#L151-L154

https://github.com/dschatzberg/genesis/blob/290c66737c57d50e94e90b69aa404eeee0f4075b/src/memory/mod.rs#L117-L133

[hawkw]

i think this trait ought to have an associated constant for the size of frames allocated (and arch cache line size?) so we don't need to know that in ALARM ...

[hawkw]

currently up in the air:

• mutability/thread safety:
  • do we put the frame allocator in a mutex and take &mut self, or have the allocator own a mutex/cell and take &self?
  • this needs to be consistent with the allocator api ---> check what the stdlib does
• do we return Option<Frame> or Result<Frame, AllocErr>?
  • since page allocations are all the same size, we don't need to return a Layout when we OOM, all alloc requests are the same size, so we don't need AllocErr
  • similarly, we should never have to return the AllocErr::Unsupported case...
  • but, AllocErr seems more semantic than Option...

[hawkw]

would welcome input from @croyzor et al. on this...

[hawkw]

so the allocator API takes &mut self, which goes somewhat counter to my opinion that the frame allocator implementor ought to own the mutex strategy. hrm.

[hawkw]

i think if we add a FRAME_SIZE constant to the frame provider trait, we can bound Frame: Into<*mut [u8; FRAME_SIZE]> or something, which seems ideologically correct to me.

[hawkw]

Started: #22