Hi all,
I'm at the point in my journey that I'd like to be able to start writing userland software in Rust - specifically right now, although not ultimately relevant to my question, I'd like to start on an init system, as well as move the terminal emulator into a usermode program instead of in the kernel.
So, I'm trying to port Rust stdlib. My kernel is in Rust, it makes sense that my system software is too. I'm synthesising from the Wiki a bit, but I didn't really want to have to maintain both a set of ports in cstdlib (mlibc), and a set of ports for Rust, as that's doubling up and an awkward way around. So, I set my target evnironment to unix, so I can make use of a bunch of existing work.
Now Rust is complaining about a bunch of missing types in the libc crate. I can see that some other systems (Redox was the one I looked at mainly) simply enumerate sundry C types in a conditional crate, along with error constants etc.
That then introduces the problem of I need to change libc. Which I'm not necessarily afraid to do - although it does again introduce some double-handling I have to now do, which I'd sooner avoid - however, I don't see any elegant way to make my compiled Rust runtime use my custom libc, without having to upstream some stuff. I'm loath to upstream at this stage, if I can help it, as that then (a) introduces a maintenance burden on the Rust team for a, right now, very toy OS, and (b) introduces a maintenance burden on me to ensure that always works, when in reality there are times where I go a while working on other projects, not my OS.
So, I'd like to be able to do this without introducing that maintenance burden. I'm a little surprised it doesn't use bindgen, but apparently not - that'd have made life very easy, as then I can just point it at my standard library and have done.
What's left?
- Using bindgen isn't really an option, as libc isn't set up that way - unless there's a way to bludgeon it into doing that?
- Modifying libc isn't an option, as it's in a different repo from rust, and that means upstreaming.
- I could change my OS target to be something else - newlib, a BSD, etc? That doesn't really feel like the right option, I have a feeling this will come back to bite me, although I haven't fully explored the option space. At the very least, Venix isn't a BSD, and it isn't using newlib, so that doesn't feel right.
- Modify libc locally and somehow point x.py to use it. I couldn't work out a way to do that, though - there are a bunch of crates built by rust as part of stage 1 (and stage 2, for that matter), some using libc and some not. A local registry needs Cargo.toml updates, as does a local version pointed to by a repo. That's a very invasive, and very brittle, change.
I feel like I'm slightly now out of options, so I'm throwing it over to the collective wisdom to see if anyone else has done this, and what the right solution is.
Code if it helps (although I don't think it's relevant to this particular question): https://github.com/os-venix/Venix