What's the deal will all these names: M3, MRX, MRO?
Can I develop containers on Windows or MAC OS?
I imported a container on my device - how can I access it?
Why can't I ping my new container?
The VM is slow/uncomfortable/etc, do I have to use it?
Can I use the "shared folder" feature of VirtualBox?
Why can't I use my WLAN interface to bridge to the VM?
Why doesn't start the VM at all?
How can I start to compile everything that is available?
How should I begin with my own C/C++ application development?
Where do I get a build script for the open source project X version Y?
Why is there no /dev in my container rootfs?
M3 is the name of the product platform. MRX, MRO, LSX are products implemented on this platform. All containers can be installed and run on all devices build upon the M3 platform.
Yes, because the SDK is within a virtual machine.
There are other programming languages, which do not need a cross compiler like Python or already come with a cross compiler like Go (read HowTo_Go_1_Intro.md). Using one of these and use the routers capabilities to export containers and you will be fine.
Most of the times a fresh container contains an SSH or telnet server. There will be a user with user name "root" and password "root". It is strongly recommended to change the root password with the command "passwd". It is also a good idea to add another user for further operations.
Checklist:
No, absolutely not. The SDK should be a reference. It should be most robust, light weight and flexible. It isn't the most fast or comfortable way to cross compile. Alternatives:
Yes, it's possible to share files with the SDK this way.
Be aware that there are problems/limitations:
VirtualBox does not allow to follow symlinks as a security measure to avoid, that users leave the Shared Folder. You must allow following symlinks. Stop the SDK and use the command
VBoxManage setextradata "VM_NAME" VBoxInternal2/SharedFoldersEnableSymlinksCreate/"SHARED" 1
Depending on the file system of the shared folder there can be problems with permissions, or the ownership (UID, GID) of the shared files. That might make it necessary to mount the shared folder manually in the SDK:
"$ mount -t vboxsf -o uid=1000,gid=1000 folder_to_share /mnt/mount_point_in_SDK".
A lot of WLAN chipsets do not support bridge mode. You will not get an error if you try to bridge a WLAN interface to the VM, but in most of the cases you will not get any traffic through to the VM. If you have to use WLAN (e.g. you have no Ethernet port) you will have to connect to the VM via NAT and use different IP networks on your host and within the VM.
Depending on your host system it can be necessary to modify the settings, especially "Settings -> Processor". More information can be found at the VirtuaBox vendor site: https://www.virtualbox.org/wiki/User_FAQ
The /scripts/mk_all.sh is doing exactly that: It deletes all files that have been generated by former script executions, then it builds all open source project and finally creates all the available containers.
Have a look at ./closed_source/hello_world. Use this as a template for your own application. Do not forget to enter your binary in the rootfs list (./scripts/rootfs_lists/default.txt), so your application will be included next time you pack a container.
Make one yourself and share it via GitHub! This applies also in case a build script exists, but there is a newer version of the project or you need modified compile options. Go to github, fork the repository, add or change build scripts and add a new pull request on github. Begin with the already existing template "./oss_sources/scripts/template.sh".
The router firmware will check if /dev exists within the rootfs of the container. If that is not the case, the router will create the directory and all necessary device nodes on its own. This is to enable non-root users to pack a container. Dealing with /dev and its device nodes require root permissions. This should not be necessary for packing a container.