Syscall/Driver interface

_intro.md

Interface for/to Drivers

Drivers implement the Driver trait --- command and subscribe methods that correspond to command and subscribe system calls for that driver.

The subscribe system call comes with access to a Callback. Callbacks encode the process that invoked the syscall, and the function pointer passed as a callback. Callbacks also act as a capability to allocate memory from the application's heap space.

Questions

• Should Callback and memory allocation be separated
• Should command be allowed to allocate memory
• Should drivers be allowed to allocate memory from applications whenever they want, or just within a subscribe and command body.

app_ptr.rs

pub struct AppPtr<T> {
    inner: *mut T
}

impl<T> Deref for AppPtr<T> {
    type target = T;
}

impl<T> DerefMut for AppPtr<T>;

callback.rs

// A Callback is minted by the scheduler and encodes a callback to an application
pub struct Callback {
    // We want more expressive types for this. For now, the kernel is expected
    // to unsafely cast these to `Process` and `fn()`, respectively. Even these
    // types, however, leak some information about the calling application that
    // we probably shouldn't leak.
    process_ptr: *mut (),
    fn_ptr: *mut ()
}

impl Callback {
    /// Creates a new Callback for the given process and function pointer.
    pub unsafe fn new(process: &mut Process<'static>, fn_ptr: *mut ()) -> Callback;
    /// Schedules the callback to be run by the scheduler
    pub fn schedule(&mut self, r0: usize, r1: usize, r2: usize);
    
    pub fn app_alloc(&mut self, val: T) -> AppPtr<T>;
}

driver.rs

pub trait Driver {
    fn subscribe(&mut self, subscribe_type: usize, callback: Callback) -> isize;
    fn command(&mut self, r1: usize, r2: usize) -> isize;
}