Refactor Bootstrap.File

[cevans87]

The boostrap file API needs to support submission of the following system calls into the executor's ioring instance. The same is true for completion. The completion API should support direct completion, e.g.

let s = File.Read.submit buf file in
let c = File.Read.complete s

The file API needs to be build on top of the Submit and Complete API such that it closely matches the following Hemlock API

val File:
    val Read:
        val Error:
            type t

        val Id:
            type t = uns

        val Submit:
            type t
            val id: t -> Id.t

        val Complete:
            type t = result Error.t bytes
            val id: t -> Id.t
            val container_hlt: t >hlt-> _&slice _&bytes

        val submit: uns -> File.t >os-> Submit.t
        val complete: Submit.t -> Complete.t

    val read_hlt: uns -> t >hlt-> _&slice _&bytes
    let read n t = Read.submit n t |> Read.complete |> Read.Complete.container

Supported file operations.

• Refactor Boostrap.File.open #161
• Refactor Bootstrap.File.close #162
• Refactor Bootstrap.File.read #163
• Refactor Bootstrap.File.write #164
• Refactor Bootstrap.File.seek #165

[jasone]

Re: Hemlock syntax, note that currently modules are e.g.

val File:
    val Read:
...

The capitalization is what gives them away as modules.

Someday we may have a parser which catches these things. 😉

[jasone]

We've talked some about whether receive needs special syntax, but IIRC didn't come to any final decisions. Should we open an issue for receive?

[cevans87]

Should we open an issue for receive?

I just started opening one, but realized that I basically duplicated #148.

[jasone]

Hehe, it's a good thing we write things down!

[cevans87]

Notes from a conversation today.

We talked about the safety of providing buffers to read and write, and decided that we can do a few things at runtime to ensure that only the actor or only the kernel can write to an IOBuf at any given moment, but we couldn't come up with a solution that was both simple and didn't have serious drawbacks. For now, we're going to say that developers will need to take care when using an IOBuf that they don't read or write it while submitted to the kernel for work. So, despite the obvious danger in the API, we're not putting guards in place. So, something like the following will be possible.

let buf = IOBuf.init 1024
# set the contents of buf to something...
let submit = File.Write.submit ~buf file
IOBuf.put 0 '\0' buf  # Obviously a concurrent write bug with the kernel.
let complete = File.Write.complete submit

[cevans87]

I'm almost done with the open command. I think it's the trickiest of all the five calls since it takes a char * pathname argument that must be valid and non-moving in userspace for the entire time the kernel handles the submission. The other four system calls should be simpler.