<qyliss>
Suppose I could just lump this in with the wayland device maybe...
cole-h has joined #spectrum
<qyliss>
gonna go and do some Thinking for a while about this, because it's not at all clear to me what the best way forward is
<qyliss>
I'm thinking of maybe adding the concept of a "server" to crosvm, as something distinct from a device
<qyliss>
Because this really isn't a device at all. It's just a server that accepts on a socket and talks to another socket.
<qyliss>
The only thing it has in common with a device is that we'd want both of them to be sandboxed since they communicate directly with a guest.
<qyliss>
And having some virtio_wl-based server mechanism feels like it could pay back substantially in the future for other services we want to provide to VMs
<qyliss>
I should review how device sandboxing works to see if it can be reused
<MichaelRaskin>
Well, what is the conceptual difference between device and server or service?
<MichaelRaskin>
Note that they seem to allow input devices provided as normal sockets…
<qyliss>
"device" in crosvm really means PCI device
<qyliss>
something that has a kernel driver on the guest side
<MichaelRaskin>
Well, here you will have virtio_wl or its refactored generic version, no?
<qyliss>
No, virtio_wl has a device already
<qyliss>
I just want to provide a socket to that device
<MichaelRaskin>
Won't it be just another socket passed through virtio_wl mechanism?
<qyliss>
Yes
<qyliss>
But that's very different to the device that actually implements the host side of virtio_wl
<MichaelRaskin>
Sure, but why is it worth differentiating from the very notion of device?
<qyliss>
I think so
<qyliss>
like, none of the device supporting code applies to this
<qyliss>
I had assumed that this would be a device at first, but reading the code has convinced me otherwise
cole-h has quit [Quit: Goodbye]
cole-h has joined #spectrum
IrinaMats has joined #spectrum
IrinaMats has quit [Client Quit]
<qyliss>
crosvm device jailing is tied to being a "bus device", so also not useful for this
<qyliss>
which is fine, because it's just a wrapper around minijail
<qyliss>
But yeah, I guess I'll add some part in the VM initialization process that creates "servers", of which this will currently be the only one.
<MichaelRaskin>
Hmmm, and what is the status of their 9p code?
<MichaelRaskin>
Even if we cannot run it, how is it structured?
<qyliss>
I suspect the 9p device just speaks virtio directly, just like the block devices and stuff
<qyliss>
But I'll check
<qyliss>
Yeah, that's exactly how it works
<MichaelRaskin>
So it does not need the extra layer? Ah.
<qyliss>
Yeah
<Irenes[m]>
yeah I think that server architecture makes sense fwiw
<qyliss>
Oh I should update the binary cache in preparation for cole-h being done with finals :P
<Profpatsch>
cole-h is already migrating the lorri ci :)
<cole-h>
Hahaha. I'm getting close -- 3.5 pages out of 5/6!
<qyliss>
what a hero :D
<cole-h>
Profpatsch: :^) Or at least improving upon it.
<cole-h>
I love that a lot of Nix-related (or at least -adjacent) stuff is written in Rust
<cole-h>
Makes it a blast contributing
<Profpatsch>
I think all nix tooling should be Rust or Python
* cole-h
salivates.
<Profpatsch>
It decreases bootstrapping problems and gives a minimal set of things that people have to understant
<Profpatsch>
*d
<MichaelRaskin>
This includes a from-scratch Nix expression parsing rewrite? Hm…
<Profpatsch>
At least 3rd-party tooling
<qyliss>
Rust is not easy to bootstrap at all
<cole-h>
Doesn't Rust have bootstrapping problems?
<Profpatsch>
rewriting nix is going to be peacemeal.
<qyliss>
We've had a pretty unenthusiastic reception to bootstrapping Rust in nixpkg
<Profpatsch>
I mean bootstrapping in the sense of: right now people tend to write tools for languages in the same language
<cole-h>
(Sorry, but: piecemeal)
<MichaelRaskin>
I think we have some useful tooling based on hnix by now?
<Irenes[m]>
my recommendation is crate2nix rather than carnix
<qyliss>
Yes crate2nix is very good
<cole-h>
I personally really like naersk... but I also haven't looked at crate2nix recently.
<cole-h>
Or ever, really
<Profpatsch>
buildCargoPackage is super
<qyliss>
Naersk means you need to rebuild all your dependencies every time one of them changes, which is quite a shame
<Profpatsch>
you don’t need tools, you can just manually specify the packages.
<Profpatsch>
And put stuff in `dependencies`
<Irenes[m]>
yeah I'm fine with buildCargoPackage but I do feel the need for tooling on top of it
<MichaelRaskin>
Well, for large enough dependency list one _wants_ to semiautomate the conversion
<Profpatsch>
But not for bootstrapping
<Irenes[m]>
I've found that I want to be able to actually use cargo to do builds, when I'm developing, because going through nix every time will do more wasted recompilation
<qyliss>
Binary cache up to date :)
<Profpatsch>
Irenes[m]: Joke’s on you, cargo relinks on whitespace changes
<Irenes[m]>
so that means developing with Cargo.toml and letting the nix equivalents be mechanically generated
<Irenes[m]>
lol
<cole-h>
qyliss: Hm, that's fair. I think I did look at crate2nix, but I ran into some issues... But I don't remember what they were :D
<Irenes[m]>
fair lol
<qyliss>
The problem with crate2nix is that it basically has to reimplement Cargo
<Irenes[m]>
I have not tried naersk
<Profpatsch>
qyliss: no, it doesn’t
<qyliss>
That was what the author told me
<Profpatsch>
It uses buildRustCrate
<qyliss>
Okay, crate2nix + buildRustCrate has to reimplement Cargo
<Profpatsch>
Which works pretty much as it should
<cole-h>
lol
<Irenes[m]>
yeah it reimplements Cargo
<qyliss>
In most cases, yes. There are occasionally edge cases, which is the downside of crate2nix.
<Profpatsch>
cargo is not the best package manager tbh.
<Profpatsch>
Most of the time the
<Irenes[m]>
but like
<qyliss>
In theory, with minor changes to Cargo we could probably have a Nix tool that reads Cargo.toml and does incremental builds.
<Irenes[m]>
carnix is built on buildCargoPackage and tbh it still has to reimplement Cargo
<qyliss>
While using Cargo
<Profpatsch>
compromise between reimplementing a mutating package manager and trying to wrap it while working around all the weirdness is very close
<Irenes[m]>
because you need the dependencies to be legible to nix
<Profpatsch>
Maybe rustc should just provide a reasonable mid-level interface so that you don’t need cargo *shrug*
<Irenes[m]>
yeah maybe
<Profpatsch>
Same problem with Haskell, but wtih 20 years of legacy and lots of weird experiments
<Irenes[m]>
I admit I've been focused on making my stuff work rather than on the long term
<Irenes[m]>
please don't get me started on Cabal lol
<Irenes[m]>
the people developing Cabal are good people who want the best
<Irenes[m]>
and it is a well-thought-out architecture
<Irenes[m]>
and yet I still have so much frustration with it
<Profpatsch>
bit?
<Profpatsch>
*but
<Irenes[m]>
no, this would be a waste of everyone's time, let's stay focused ;)
<qyliss>
I should write another script to garbage collect the binary cache
<qyliss>
they grow fast, turns out
<Irenes[m]>
ah yeah
<Irenes[m]>
no doubt
<qyliss>
really what I'd like is a way to keep the spectrum-specific stuff but not the stuff Hydra already has
maxdevjs has quit [Remote host closed the connection]