5 ms·

Which language is the sample code written in? Looks.... awful.

• mhh__ 9y ago
  Rust?
  • deleted 9y ago
    [deleted]
  • simcop2387 9y ago
    Looking at the blog's source, yes rust (and the code looks like rust also). https://github.com/rabbitstack/rabbitstack.github.io/blob/master/operating%20systems/linux-containers-internals-part-i/index.html#L177 https://github.com/rabbitstack/rabbitstack.github.io/blob/ma...
• archrabbit 9y ago
  it's Rust. Btw, did you see erlang or clojure? ;p
  • striking 9y ago
    What's the point of writing your program in Rust if it's almost entirely wrapped in `unsafe{}`? You'd be better off just writing a C program. It could even be clearer to a wider audience what exactly you're doing.
    • archrabbit 9y ago
      I probably could wrap in the `unsafe` block just the invocations to the system calls. I'm learning Rust and I wanted to give the post some freshness. There are already a plethora of examples in C.
    • tiles 9y ago
      That's a bizarre argument; the post is about writing an abstraction over another interface, and it's clearly meant to be extended. The abstraction can be written in a safer language than C. Seems like there's an obvious upside.
    • gtirloni 9y ago
      With Rust you can at least have some certainty of where problems could happen. It gets boxed inside unsafe and affords extra scrutiny. You don't have to worry much about everything else surrounding you code. Disclaimer: only went through basic tutorials and I don't program in Rust daily.
    • deathanatos 9y ago
      The large unsafe call inside pivot_root is much larger than it needs to be. It only needs to encompass the mount() call in that function. It's a pretty trivial change to have it only wrap the if. (Though it could wrap less, but that would either look uglier or need a variable binding the result, which honestly wouldn't be that bad either.)
• deathanatos 9y ago
  There's some places where this example could be better written. For example, this: let oldrootfs = String::from(format!("{}/.oldrootfs", rootfs.clone())); can be reduced to either of: let oldrootfs = format!("{}/.oldrootfs", rootfs); let oldrootfs = rootfs.clone() + "/.oldrootfs"; You could also do something like Path::new(rootfs).join(".oldrootfs") but I'm not entirely sure how to get that to a pointer for the FFI stuff. It seems like the smartest way would be to go through OsStr, and if one wanted to use Path instead (which seems like the appropriate type), then sys_pivot_root should probably be changed to accept them instead. A lot of the complexity here is that you're interfacing with C, which is inherently unsafe, and cdecl is very simple in what can be passed. (And stuff like POSIX file paths are just hard to statically type around, because they're not text strings.) Normally, you'd write some wrappers (which the original author is well on the way to), and the rest of the code should look much simpler. Similarly here: create_dir(oldrootfs.clone()); The clone isn't needed; you can simply borrow oldrootfs: create_dir(&oldrootfs); If you change rootfs in both pivot_root and sys_pivot_root to a &str, you can then call it as just pivot_root("/") which is simpler than pivot_root(String::from("/")) (I generally find that taking &str is simpler than String, if you're not going to modify the String object.)
  • archrabbit 9y ago
    Sure, there is definitely a lot of possible improvements for the code examples, like avoiding `clone` on a heap allocated strings, etc. I had some really odd issues when passing a statically allocated strings to the `libc` functions (the function's arguments from the previous calls ended up concatenated in the later function's invocations, just use `strace` to observe that behavior).