API/documented process to port to new OSes?

[Connor-GH]

target-triple: x86_64-unknown-none

OS: https://github.com/connor-gh/xv6-public

This is different from the newlib request. There are hundreds of libcs, it's just that only a few are complete, and even few are good. My libc falls into the "incomplete and bad" category, and so it doesn't make sense for me to add a config option upstream to use this crate. I should be able to define a file that contains my special kernel interface and be done with it, essentially. I should make like a build.rs or a lang-item or something and pass --cfg relix and expect everything to just work.

For some clarification:
Relix uses a custom libc and kernel. The system is to be compiled without a cross-compiler (using any ELF gcc or clang). An appropriate target for Rust would be x86_64-unknown-none so that it avoids glibc-isms. Look at this OS wrapper: https://github.com/rust-lang/libc/blob/main/src/trusty.rs. It doesn't seem productive for me to add my obscure OS wrappers upstream, so a downstream solution is what I am looking for.

[Connor-GH]

My endgoal is to port the libc crate so that the std crate would "just work" with std::fs and std::io. Although it would be nice to see those crates being no_std (and I know some progress is being made), that is going to take longer. Also, this should probably be done regardless.

[tgross35]

You are talking about support for a new OS, correct? Since OS+libc is part of the triple, the usual path is to add a new tier 3 target - I don't think it would be any easier to somehow use libc and part of std on top of unknown-none.

It's pretty trivial to add a new target, see https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#adding-a-new-target. After that exists, support could be added to libc at any time.

[Connor-GH]

And this is something you all are willing to do? To add support for some OS that might not exist tomorrow?

[tgross35]

Not me personally, that would be anyone interested enough in being a target maintainer and the rest of the tier 3 policy is met then I don't think longevity is the biggest issue. That would be a prerequisite for any changes to this repo (as target acceptance shows we have some level of rust-lang interest/support) but if that isn't what you are asking, could you clarify what the goal is?

[Connor-GH]

That is what I am asking; it's just that this is surprising because I don't find any projects that are willing to do this.

[skyevo938]

Not me personally, that would be anyone interested enough in being a target maintainer and the rest of the tier 3 policy is met then I don't think longevity is the biggest issue. That would be a prerequisite for any changes to this repo (as target acceptance shows we have some level of rust-lang interest/support) but if that isn't what you are asking, could you clarify what the goal is?

[tgross35]

because I don't find any projects that are willing to do this.

Do you mean other microkernels that want support of a Rust toolchain? We do get these occasionally, see e.g. #4355 for a recent example. If it's super experimental though then you might be able to get by using the linux-gnu or linux-musl target if you have a somewhat compatible libc (probably a lot of linker errors depending on what functionality you use if it's incomplete, but that gets you off the ground). Or if there aren't likely to be many other users then you can probably maintain a fork yourself, either of rust-lang/rust to add the target, or only of rust-lang/libc with your proposed cfg(relix) (that's just not something we could merge here).

[tgross35]

I'm going to close this since I don't think there is anything actionable at this time. But I'm happy to keep answering any questions here if it helps, or you can drop in the chat https://rust-lang.zulipchat.com/.