Hacker News Reader

Comment by uluyol | Hacker News Reader

So starnix is a tool being worked on at Google (in Rust, [1]) to implement Linux's syscall layer and is validated against test cases [2] written for gVisor, also a program that implements Linux's syscalls, but one that is instead written in Go [3].

I see NIH is growing even stronger at Google. Why not build on gVisor, rather than re-implement everything from scratch?

[1] https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...

[2] https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...

[3] https://gvisor.dev/

View on HN

Long story short: "gVisor uses host-native abstractions, such as threads and memory mappings, to co-operate with the host and enable the same resource model as native containers."

When the host isn't Linux...

gvisor is a Google project, this isn't NIH.

gVisor provides a linux syscall interface to the guest, but ultimately calls a linux syscalls when it needs to invoke something in the host. That obviously doesn't work for a linux-on-fuschia compat layer. I guess you could re-use the guest side, but if gVisor wasn't written for pluggable backends it's probably more work to do that refactor than just build a separate tool.

From the outside looking in, it's seemed that Not Invented by this Team is just as likely a factor as NIH at google.

> That obviously doesn't work for a linux-on-fuschia compat layer.

This isn’t actually true. gVisor contains full implementations of Linux syscalls and only relies on host syscalls being the same for some interoperability features between sandboxed and host applications. It would be completely possible to port gVisor to a non-Linux operating system.

Right, it would be silly to intercept the syscalls and just pass them on as is to the host kernel. If you just want to validate/filter things for security reasons, there are existing Linux APIs for that.

"implementing linux syscalls" ==> a million tools.

I'm not sure it's strong logic to re-use something else because it implements linux syscalls, the hard part is what it does after it receives the syscall.

I believe this is entirely motivated by this policy: https://fuchsia.dev/fuchsia-src/contribute/governance/policy...

For starters, gVisor is written in Go, which by design won’t have performance of C++/Rust.

Citation required on this one...

gVisor is used in a lot of places[1] that require more performance than a clock. I'm not saying you can't achieve more performance with C++/rust, what I'm saying is that this probably isn't the primary concern.

1. https://cloud.google.com/kubernetes-engine/docs/concepts/san...

https://www.usenix.org/system/files/hotcloud19-paper-young.p...

https://gvisor.dev/docs/architecture_guide/performance/

https://gvisor.dev/docs/architecture_guide/performance/#netw...

Network performance in gvisor is awful and, by gvisor's own documentation, this is a matter of "implementation costs" ie: it is how gvisor is written, not gvisor's fundamental constructs, that makes it slow.

The rest of the benchmarks are notable as well, there are a few other places where the implementation is called out as being a problem.

So maybe they should team up and work on replacing gVisor with something that shares as much code as possible with this new thing, which one would hope would be architected in a way to be able to help replace gVisor?

Or maybe not?

Yeah, of course: if you are the kind of company that like a having tens of thousands of engineers working on five different versions of the same thing, with one team explicitly working on solving a problem another team has but without helping them as that's some combination of not-fun and not-promotion-worthy, you can of course do whatever you want.

Or they have context that helped them decide to do something this way?

lol, sure.

Some obvious context from an outsider:

1. It's designed to run on Fuschia, not Linux

2. Go FFI is very inefficient, you can't just "extend" a Go project with native bindings and get the same performance wins

3. Hopefully the gvisor team learned the obvious lesson that Go is not suitable for this kind of work

Not everything needs to be molded into a common base that serves the needs of all. Fuchsia has different constraints than the ones gvisor is written for and choosing to not try to morph gvisor into something it doesn't want to be is okay. Optimizing to solve problems should be the goal. Sharing code is nice to have where it makes sense.

The context here was that gVisor was a suboptimal way to solve the problem and they know that... so I am not sure in what point you are trying to make by saying people can optimize to solve problems unless you actually mean people can optimize to not solve problems.

Why?

> Citation required on this one...

You mean you'd like to read a source to back up that statement.

Nothing is required...

That's false: you're assuming perhaps reliance on the garbage collector, and overlooking escape analyses (the compiler pass) enabling entire classes of Go programs indistinguishable, after code generation which obviates the garbage collector from user code at least, from optimized C++/Rust.

gvisor performance is terrible and rewriting it in Rust gives me hope that I can finally use it

Note that starnix is not a rewrite of gvisor and in particular will not be portable to non fuchsia systems.

Bummer

This isn't NIH.

There are links between Silicon Valley, Google, Rust and their ideology.

Reply on news.ycombinator.com