Use Slightly Higher Level Types

[grahamc]

A lot of places in the code use base level types to mean lots of different things. For example, ReplyCreated:

pub fn created(
    self,
    ttl: &Duration,
    attr: &FileAttr,
    generation: u64,
    fh: u64,
    flags: u32
)

I propose creating types called GenerationId and FileHandleID etc. which are .into()d when passed to the kernel. This way, it is more difficult to confuse arguments and values by mistake. This is especially true when calling the created function, since you don't even have the benefit of naming the argument being passed. What I mean by this is constructing a struct it would be easier to tell the mistake:

Foo {
  generation: fh,
  fh: generation
}

vs:

created(duration, attr, fh, generation, flags)

[cberner]

Thanks for the suggestion. I think this is a good idea. Although, if I understand correctly it would be a breaking change to the Filesystem API. I don't want to introduce breaking changes unless they're necessary. I'll consider changing this if I make a bigger update to that API though. I'd like to add support for async at some point, and I'm sure that will result in a large change

[siscia]

Since we are talking about changes to the API, I was working on an API that returns a Result<Something, ErrorCode> instead of using the (I think) awkward Reply API.

[wmanley]

I created such newtypes in #119, but they're not yet exposed as public API. I'm working towards that in #136, tracking issue: #138.

[cberner]

Closing due to inactivity, but feel free to re-open if you're still working on this.