Ideas - Feel free to post ideas.

[utam0k]

Feel free to post ideas.

[YJDoc2]

Hey, this seems like a really cool project, specially as I am interested in both rust and stuff related to OS.
I was going through the code and even though it seems quite understandable, it'd be great if there was a high level guide or even comments giving an outerview. I saw that the design and implementation section is TBD in readme, and even though I don't have much knowledge of container runtime, I would like to help writing docs or guide as it'd help me to understand it as well. Do you have anything specific in mind regarding such guide, or maybe can you open an issue regarding this, so we can discuss this there? Thanks!

[utam0k]

@YJDoc2
Thanks for the comment!
Currently, I have no idea about this yet. If you have any good ideas I'd love to hear them.

I saw that the design and implementation section is TBD in readme, and even though I don't have much knowledge of container runtime, I would like to help writing docs or guide as it'd help me to understand it as well.

I think it might be a good idea to start with commenting on the code.

[YJDoc2]

I think as implementation will grow, the documentation will become complicated, so rather than adding in Readme, having a dedicated 'thing' will be better. One way could be adding a repo wiki like this : https://github.com/dthain/basekernel/wiki
Or other option I can think of is having an mdbook like rust language, and maybe hosting it on github pages for this repo.

I will try to start commenting and make a PR. Can you give me any links for references of this? Also, in case of any doubts I'll message in thread or on twitter if you're fine with it.

[utam0k]

It's nice!

I will try to start commenting and make a PR.

You would use https://docs.rs, right?

Of course! I welcome questions from you on Twitter and elsewhere.

Also, in case of any doubts I'll message in thread or on twitter if you're fine with it.

[YJDoc2]

Hey,As far as I know, docs.rs automatically makes and hosts the html documentation using the doc comments in the source, when crates are uploaded on crates.io .
I was talking about adding the in-source comments to explain structures and fields and functions etc, using doc comments according to conventions in
https://doc.rust-lang.org/book/ch14-02-publishing-to-crates-io.html
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text
If you had something else in mind, let me know because I haven't worked specifically with docs.rs before, even though I have done documentation commenting for some of my projects.

[utam0k]

@YJDoc2
I feel that docs.rs also automatically generates the descriptions for struct and functions, etc.
https://docs.rs/futures/0.3.15/futures/io/struct.AllowStdIo.html
This is the code that will generate the comments for this document
https://docs.rs/futures-util/0.3.15/src/futures_util/io/allow_std.rs.html#43

At any rate, the current situation is that there is nothing to comment on, so adding a comment would be very meaningful and appreciated.

[utam0k]

I created utam0k#14

[tsturzl]

I was thinking it might be possible to use async/await to concurrently handle cgroup controller configuration. This might be a pretty minor improvement to performance since these IO operations are relatively small, but might be worth looking into.

[utam0k]

@tsturzl
That's a very good idea. I was actually wondering if I could use some of that.
According to railcar's article, it seems that creating a cgroup waits for a kernel lock.
I'm thinking that using async/await for cgroups might actually improve performance a bit.
Are you interested in this?

[tsturzl]

@utam0k I've been reading through some of the runc source while writing the memory controller. It seems like order of writes to certain files within a controller matters in some situations. I believe it might have to do with validation between 2 values in the kernel. See: https://github.com/opencontainers/runc/blob/master/libcontainer/cgroups/fs/memory.go#L89

I'd be happy to take look into it. Maybe once the cgroups controllers all implemented so I don't disrupt anyone's work. I think perhaps a good starting point might be to just ensure order of writes within each controller. That way each controller can be configured concurrently, but still ensure writes within a controller are happening in a certain order to avoid validation issues.

[utam0k]

@tsturzl
Your ability to read the runc code so quickly is amazing! I'm still getting used to it and can only read what I need little by little.
The use of async/await is a great advantage that youki has implemented in Rust and I would love to incorporate it.
Can you create an issue about it? I'll assign it to you.
And when it's done, I'd love to invite you to be a member of this repository and work with you.

[stappersg]

IPv6 support. See also #24

[tsturzl]

Should Youki come up with some kind of central objectives or further out design goals? Perhaps it's too soon to tell, but some easier objectives could be just an emphasis on safety and speed. Eventually it might be nice to have some kind of goal beyond just having a workable runtime, since it seems like we're surprisingly close to having a totally functional runtime. Something to think about and discuss maybe?

[utam0k]

@tsturzl
I think it's a great time to think about some big final goals.
When I first started making it, I started with the same thoughts as those in the railcar release blog. So basically, I think there is a big point in implementing it in Rust, just as there is in the linux kernel. It's a big advantage that Rust can break through the linguistic difficulties of Go and C, which are the current typical implementations.
https://blogs.oracle.com/developers/building-a-container-runtime-in-rust

Also, I would like to challenge performance.
However, if you have any other good goals I would love to hear them. I think youki right now is a pretty good place to try it out as it is not yet in the practical stage.
I think it is of course possible to offer it as a crate as well as a crun.
If you have any interesting challenges, I'd love to hear about them.