[Vm-dev] Packaging 64-bit and 32-bit linux VMs

K K Subbu kksubbu.ml at gmail.com
Fri May 25 04:04:22 UTC 2018


On Friday 25 May 2018 01:49 AM, Eliot Miranda wrote:
> Hi Subbu,
> 
> On Thu, May 17, 2018 at 4:44 AM, K K Subbu <kksubbu.ml at gmail.com 
> <mailto:kksubbu.ml at gmail.com>> wrote:
> 
> 
>     On Wednesday 16 May 2018 11:55 PM, Eliot Miranda wrote:
> 
>         IMVER=`hexdump -n 4 -e '"%u\n"' "$IMAGE"`
> 
> 
>     od may be a better choice as it can handle endianness too. E.g.
> 
>     $ od -A n -t u4 -N 4 --endian=little squeak.image
>       6521
>     $ od -A n -t u4 -N 4 --endian=big squeak.image
>       2031681536
> 
> Doesn't work on Mac OS X
You're right! I didn't think of OS X since the subject was about Linux 
VMs. But I won't be surprised if it breaks, because core CLI utils on OS 
X have not kept pace with time.

The problem of a portable way of binding VMs and images at runtime is a 
serious one. Now that we are faced with a sparse matrix of VMs and image 
file combinations, the problem will only get worse with time.

I see two options (not exclusive) towards a long-term solution:

  #1 generate mimetypes for VM app and image files at build time and use 
Info.plist/xdg-utils to complete the binding at install time.

  #2 Use a tiny bootstrap image and write all runtime scripts in st 
itself. The VM will always start with this bootstrap which will then use 
st scripts to probe the given image and then bind it to the right VM.

My own preference would be to create mimetypes at build time rather than 
postpone the problem to run time.

The second option sounds more complicated with two images, but there has 
always been a demand for a tiny headless REPL image and many people have 
created their own kernel. Bundling one with the VM will gives us a 
reference shell and the same can be used for builds and customizing 
runtimes.

Regards .. Subbu


More information about the Vm-dev mailing list