qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<pie_> soooo the answer im getting out of this is "its possibly via VM suspension and wayland will give you seamless windows" "...eventually"
tilpner has joined #spectrum
tilpner has quit [Remote host closed the connection]
<MichaelRaskin> So, is all the work still with squashfs and not 9s?
tilpner has joined #spectrum
pie_ has quit [Ping timeout: 268 seconds]
pie_ has joined #spectrum
<MichaelRaskin> Maybe crosvm should make its srcs available…
pie_ has quit [Ping timeout: 276 seconds]
pie_ has joined #spectrum
<qyliss> MichaelRaskin: yes, I haven't done 9p yet
<qyliss> crosvm's sources are available, as are my Nix expressions to build it
pie__ has joined #spectrum
pie_ has quit [Ping timeout: 276 seconds]
<lejonet> qyliss: :D
<MichaelRaskin> Re: srcs available — I mean, let's have less opaque let's, crosvm attribute in Nixpkgs should have a clear way to extract the srcs used
<MichaelRaskin> I know that your branch contains the expression
<qyliss> The one in the Spectrum tree has srcs :)
<qyliss> At least it should do
<MichaelRaskin> isn't it with crosvmSrc and adhdSrc?
<qyliss> Oh shit you're right
<MichaelRaskin> Guess how I came to complaining!
<qyliss> It requires a very specific filesystem layout, so it needed its own unpackPhase anyway
<qyliss> Setting srcs for it to be ignored felt wierd
<qyliss> But I suppose maybe I should
<qyliss> Or... put it in passthru or something?
<MichaelRaskin> Sure, srcs in passthru is enough
<MichaelRaskin> Given that making CrosVM print usage information without /dev/log existing is hard, nix-build'ing src/srcs to read the option parser is a very natural idea
<qyliss> Patches welcome :)
<MichaelRaskin> I am never sure which version of CrosVM expression should be merged to mainline Nixpkgs (and are all of them the same)
<qyliss> I would like to merge what I have now into mainline at some point
<qyliss> But for now the PR that hyperfekt has is probably what we want
<qyliss> Although needs an update
<qyliss> And it should have by unpackPhase
<qyliss> But there's a bunch of chromium os stuff already in Nixpkgs that depends on other chromium os stuff, so I think upstreaming chromiumOSPackages would make sense
<MichaelRaskin> Is what you have in the branch for Chrmoium actually going to change much in the near future?
<qyliss> Probably a little, but not much. But I think upstreaming it probably requires some tact and gradual-ness.
<qyliss> Because otherwise I can see people having a bad reaction to suddenly packaging half of Chromium OS
<MichaelRaskin> I think leaf additions don't get that much attention. Unless someone has some specific ideas that are not obviously unworkable
<MichaelRaskin> lispPackages have been added, expanded, and completely revamped without anyone outside the few people actually writing the expressions caring
<qyliss> hmmmm
<qyliss> I can take a look at upstreaming it once I hit the next milestone
<qyliss> Right now I kind of need to push towards that, though.
<MichaelRaskin> What is the next milestone?
<qyliss> Let me dig it out
<qyliss> I need to keep these somewhere more easily accessible...
<MichaelRaskin> Having access to what the next milestone is does sound like a useful part of pushing towards it!
<qyliss> I vaguely know what it is
<qyliss> But figure you'll want it more precisely than the vague idea I have in my head :)
<MichaelRaskin> I figure _you_ might also rethink what exactly it is and what is the optimal way there!
<qyliss> that did happen last time I looked at it :P
<MichaelRaskin> You might have learned something new about the problem domain since then
<MichaelRaskin> I wonder if there is any reason for you not to put the milestones to the website as they become firmly set
<qyliss> They're all firmly set
<qyliss> For the next year
<qyliss> And the reason I haven't just published the whole memorandum of understanding is that I'm not sure if I'm supposed to do that.
<qyliss> I've thought about pulling out just the milestones but I think I decided it was more effort than I wanted to put in at that moment in time.
<qyliss> The milestone is called "Allow isolation units to communicate"
<MichaelRaskin> So, all the tun stuff?
<qyliss> virtio_wl is also part of that
<qyliss> "Define protocols for inter isolation unit communication, Implement tools to allow isolation units to share state, Compose isolation units into single user interface"
<MichaelRaskin> Mm? I mean, you need to get networking, and having networking gives you an option to use VNC
<Shell> I think virtio_wl is 90% of the way to working
<qyliss> It is working!
<qyliss> Working well enough for the purposes of the milestone at least
<MichaelRaskin> You mean it works for VM displaying to host?
<qyliss> Yeah
<MichaelRaskin> But yeah, never says you actually need to isolate the buggiest part of the stack…
<qyliss> Partially the reason I don't really want to post these is that I don't want to get into public arguments about whether I deserve to be paid, fwiw.
<qyliss> Not that that's necessarily what was happening here, but I think it would end up happening.
<MichaelRaskin> Well, it's the question of the order of work being fone
<MichaelRaskin> I didn't want to imply the _end_ product would be bad, sorry if it was too close
<qyliss> No, you didn't do anything wrong here
<qyliss> It's just an uncomfortable area of conversation generally
<MichaelRaskin> Yeah, I guess some people have never seen milestone-based work…
<MichaelRaskin> Milestones don
<MichaelRaskin> 't need to make sense individually as long as they are in the general correct direction
<MichaelRaskin> (and can be sanely demonstrated)
<MichaelRaskin> Annoyingly, Qemu's socket-based vhost-user connection between VMs intuitively feels exposing the host less than the CrosVM's TAP approach
<MichaelRaskin> I wonder if I value my sanity enough no to consider running TAPs inside Qemu with SpectrumOS-based CrosVM instances inside.
<qyliss> Yeah TAP isn't going to be the way we do this forever
<qyliss> Good enough for a POC, not good enough for the guarantees I want
<qyliss> I'd like to investigate modifying crosvm to just pass through virtio
<qyliss> So it can be connected to another VM
<qyliss> I think it should be doable
<Shell> I'm fairly sure the connection between VMs involves the host routing stuff anyway, it's just much simpler routing than network routing
<MichaelRaskin> Well, network code does all the fancy stuff, also known as attack surface
<Shell> yup
<MichaelRaskin> I really hope unix domain socket just doesn't have the knobs to turn to 11
<qyliss> virtio doesn't really know anything about what you're shoving over it, so I'm hoping attack surface there is minimal
<qyliss> And ideally our host kernel will never actually look at what the VMs are sending over virtio, it'll just ferry messages between them
<MichaelRaskin> Exactly
<MichaelRaskin> Hmm
<MichaelRaskin> Apparently virtio-vhost-user in Qemu is just a development branch in a fork with last commit Jan 2018
<MichaelRaskin> (well, the approach worked, which raises the hopes for feasibility of a CrosVM version)
<MichaelRaskin> 1330 LOC, apparently
<MichaelRaskin> Maybe rust-vmm/vhost* gets something done in future
<Shell> isn't the vhost stuff the host kernelspace virtio parsing stuff?
<Shell> that seems a bad thing to touch for this project
<qyliss> we should be able to carry virtio between VMs by just mapping the same bit of shared host memory into two VMs
<Shell> there's a little bit more plumbing than that, but
<MichaelRaskin> They have plans for vhost-user
<qyliss> As in userspace vhost?
<MichaelRaskin> As in host part of virtio living in another VM
<qyliss> Interesting
<Shell> https://wiki.qemu.org/Features/VirtioVhostUser explanation towards the bottom
<Shell> interesting