<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