Danny Milosavljevic <dannym@scratchpost.org> writes:

> There are now three manual "-virtfs" arguments to qemu.  It's starting to irk me
> a little.  It might make sense to generate those from %linux-vm-filesystems
> in order to not have so much duplication and places where things can go wrong
> when maintaining.
>
> If you'd like, could you maybe pass the %linux-vm-filesystems to
> load-in-linux-vm and then automatically calculate those -virtfs entries?
>
> (In a future patchset - I don't wanna hold up this one)

I agree this would be nice.  I also agree we should do it in a future
patch series.

> There's already common-qemu-options which would support
><file-system-mapping>,
> and %store-mapping, so actually it would make sense to use those (probably easiest
> to move build/vm.scm's load-in-linux-vm into system/vm.scm
> expression->derivation-in-linux-vm so the qemu stuff isn't scattered all over
> the place - right now, half is in gnu/system/vm.scm and a mostly redundant half
> is in gnu/build/vm.scm ... not ideal).
>
> There's a "mapping->file-system" helper, so it might make sense to use
> <file-system-mapping> instead of <file-system> in %linux-vm-filesystems.
>
> So all in all:
>
> * Modify %linux-vm-filesystems to be file-system-mappings instead of file-systems.
> Also modify the place it is used.
> * Move load-in-linux-vm to gnu/system/vm.scm (maybe inline into caller).
> * Modify load-in-linux-vm to use common-qemu-options.
> Notice that the "-append" option is passed twice.  Bug... <-- I just fixed that in master

Good catch!  Thank you for fixing it.

> If you want I can do it.

I wish I could say "I'll do it!", but honestly I might not be able to
get to it for a few weeks.  So if you have the time, by all means please
do it!  Otherwise, I might get around to it eventually.

-- 
Chris