Hi all,
I wanted to share some details about what is planned for the Windows
port of Mynewt. There is still some work to be done, but here is a
rough description of what is planned.
Thanks to a lot of help from Todd and Ray, we have a Windows port that
is mostly working. I wanted to provide a summary to see if anyone
anticipates any major issues. I am certain that I got some of the
docker concepts wrong, so please feel free to correct any of my
misconceptions :).
Rather than create Windows ports of all the necessary components, we
just run Linux versions of all the software in a virtual machine.
Windows communicates with the Linux VM via transient ssh connections.
When the user issues a command intended to run in Linux from a Windows
command prompt, the corresponding Linux command is executed in the Linux
VM. This allows the user to utilize Linux from within Windows without
having to explicitly mess with VMs. All commands intended to run in
Linux would need to be prefaced by a script that we provide to ensure
the necessary ssh mechanism is used.
There are a few shortcomings with this solution, as described:
* There is no protection against the VM accidentally becoming
unusable (e.g., required files getting deleted in the VM).
* Upgrading any Linux tools, in particular the newt tool, requires
the user to download a complete VM containing the upgrade.
These shortcomings are addressed by a tool called Docker. When
executed, Docker creates a consistently reproducible and self-contained
environment in Linux. By creating a custom docker image, a user can
have assurance that a particular set of commands will always execute
successfully.
In addition, docker images use a layered format. To receive updates to
one or more of the linux tools, the user just needs to download the
newest layers (similar to applying a patch).
The Windows install of Docker ("docker toolbox") consists of:
* A Windows port of ssh.
* A copy of Oracle VirtualBox.
* A minimal Linux VM that runs in VirtualBox.
* The docker tool.
In addition, we would need to provide:
1. A docker image consisting of an environment with:
* The newt command-line tool
* Go
* A multilib-capable native gcc / glibc
* An arm-none-eabi gcc
* Native gdb
2. A Windows batch file (script) that allows the user to run Linux
commands from a command prompt. The batch file would also ensure
that the VM is running.
Every time the user uses the script to run a command, the following
sequence of events occurs:
1. A new docker environment is created in the Linux VM.
2. The specified command is sent to the docker environment via ssh.
3. The Linux command runs.
4. The output from the command is sent back to Windows via ssh.
5. The output is displayed in the Windows command prompt.
All the user files (C source, yml, .o, .a, .elf, etc.) reside on the
Windows file system, not in the Linux filesystem within the VM. So, the
user does not need to interact with the VM at all to manipulate any
files related to his or her project.
So that is the proposal for how the Windows port will work. My main
concern with this solution is that setting up docker in Windows 10 is
problematic. There are issues configuring the host-only interfaces
required for the ssh connections. There is a new version of the docker
toolbox to be released shortly (within a week or two) that is supposed
to address these isses, so hopefully it is not something we need to
worry about.
There are a few other issues that I have run into, but it is difficult
to tell how serious they are because of the Windows 10 problems. So, I
think we are stuck waiting for the next docker toolbox release before I
can determine what we can and cannot hide behind the batch file.
Finally, one annoyance is that this solution only works on an actual
Windows box. The Linux VM fails to start if Windows itself is already
running in a VM. I don't anticipate this being an issue for users, but
it creates quite a bit of hassle for people developing the Windows port.
Thanks for reading,
Chris
