qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<tazjin> cole-h: done ;)
<cole-h> tazjin: Nit for the future: commentary should go /after/ the --- (just before the diffstat); otherwise, it'll show up in the commit log.
<cole-h> Otherwise: woo! 🎉
<cole-h> (Unless you wanted it to show up in the commit log; in which case: hehe)
<tazjin> cole-h: yes, that was the intention :p
<cole-h> 😬
<qyliss> got lots done today :)
<cole-h> Already excited for next TWIS
<qyliss> tazjin: interesting git version you've got there
<tazjin> qyliss: :p
<cole-h> Hahaha
<cole-h> I'm ever so slightly curious about what kind of fancy patches they have going on...
<qyliss> my guess is it's gonna be mostly boring stuff like authentication with internal services
<tazjin> good guess :)
<qyliss> going to commit myself to going to sleep now by posting it on irc
<qyliss> need to have good sleep to get back into crosvm tomorrow
<tazjin> good sleep is good
<tazjin> sweet dreams!
<cole-h> o/
andi- has quit [Remote host closed the connection]
andi- has joined #spectrum
cole-h has quit [Quit: Goodbye]
<qyliss> Hmm, not really sure how to fit this compositor memory server into crosvm
<qyliss> I can't really do it where all the virtio devices get initialized, because it's not a virtio device
<qyliss> This is a nice explanation of virtio-balloon, btw, which is how dynamic memory resizing works: https://rwmj.wordpress.com/2010/07/17/virtio-balloon/
<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]
<qyliss> But that's not easy with current tools
maxdevjs has joined #spectrum
<cole-h> Maybe you could use something like this to check if it's cached: https://github.com/Infinisil/all-hies/blob/master/check-cache.sh
<qyliss> Checking it's cached isn't a problem -- I can check for a NixOS cache signature
<qyliss> Oh, I guess I could do that with --ignore-liveness
<qyliss> I didn't realise --ignore-liveness existed, and expected it wouldn't.
<qyliss> So actually this just became a non-problem
<cole-h> :D
<cole-h> Be interested to see what you come up with
<qyliss> anyway, i should be looking at crosvm
<qyliss> Oh, that's actually used for a bunch of virtio devices too, huh
nicoo has quit [Ping timeout: 240 seconds]
nicoo has joined #spectrum
<qyliss> I wrote a prototype of the actual server implementation
<qyliss> That was the easy part, though
<qyliss> The hard part will be hooking it into crosvm.