Frequently Asked Questions

Go! Tips and Tricks

1. How do I mount a windows share in the Go! virtual appliance?

Once you have shared the directory to your own userid in Windows do the following in the virtual appliance:\\
1. Create a file called /home/go/.creds containing
username=windows username\\
password=secret

2. Set the permissions of .creds to 600
chmod 600 /home/go/.creds

3. Create the local mount directory
sudo mkdir /windows

4. Add the following entry to /etc/fstab (sudo vi /etc/fstab)
//windowshost/share  /windows cifs credentials=/home/go/.creds,_netdev,uid=1000,gid=users

5. Mount the share.
sudo mount -a

Go! Design Questions

1. Why doesn't the Go! virtual appliance support VirtualBox?

We made a decision not to support VirtualBox in order to reduce our workload. The more virtualization technologies we support, the higher our testing workload, and the less time we can devote to developing new functionality. At this point in time, our primary focus is developing new features for the virtual appliance. Once the feature set gets to a certain point, adding support for something like VirtualBox could become something that we will do. VMware was chosen as the first virtualization that we support, because IT managers are more likely to allow VMware to be run on corporate servers and workstations, because it is a proven commercial product. We did not want the usage of the virtual appliance to be constrained because it relied on a technology that IT managers don't trust. Since VMware does provide a free option with VMware Player, we felt it met the needs of both worlds, i.e., IT managers and software professionals (with budgets) vs the home user (with no budget).

2. How does Go! deal with case sensitive file naming in the Linux kernel and other source code?

The Go! development environment allows a developer to check the Linux kernel source code out from the virtual appliance repository to his host NTFS filesystem to work on enhancements. Linux kernel developers have created source files in the Linux kernel whose name differs only in case, such as include/linux/netfilteripv4/iptconnmark.h and include/linux/netfilteripv4/iptCONNMARK.h. These files are a problem for Windows applications. The NTFS filesystem does support case sensitive file names, but, the Windows API does not. Thus, in Eclipse, you would see both files, but, if you open the lower case version of the file, you will actually get the uppercase version of the file in the editor. The Windows API is not case sensitive, so it can only open one of the two files. Windows now has a POSIX compliant API which would solve this problem, but, most current Windows applications, including Java which Eclipse relies upon, do not use the POSIX compliant API, but the legacy Windows API. In time, this problem will go away as Windows applications move to the new API, but, in the mean time, we actually patch the Linux kernel to give the two files unique names. All upper case file names that clash with lower case file names have u appended to their name. So, iptCONNMARK.h becomes iptCONNMARKu.h.

3. Given the problems outlined in (2) above, why don't you just use the Go! virtual appliance file system which is a Linux file system?

If we have the developer use the Go! virtual appliance file system for project source code storage, then we would avoid the case sensitive file system problem, but we would introduce other problems. If we store the project source code inside the virtual appliance, then we would also have to run Eclipse inside the virtual appliance, otherwise the problems outlined in (2) above would still exist. If you run Eclipse inside the virtual appliance, then you turn the appliance from a very lightweight virtual machine (only 256MB memory) into a heavyweight virtual machine probably needing more than 1GB memory. Additionally, you would have to start running many of the other development tools inside the virtual machine, including Enterprise Architect for UML modelling. In the end you are not really running anything on Windows, except the virtual machine, and that does not make sense. We believe that a key strength of our current Go! architecture is that the virtual appliance is very lightweight, and the heavyweight tools are all run in Windows native, and we truly take advantage of the Windows environment.

4. Why does Go! install local cross compilers when there is a compiler in the virtual appliance?

The [http://www.eclipse.org C/C++ plugin uses the GCC compiler in two distinct ways. One use is to cross-compile the project into an executable or library, the other use is to index the project so that when one clicks on a variable name they can find where the variable is defined, or where it is used. The first use is handled by the Go! virtual appliance. The second use is handled by locally installed GCC compilers. If the virtual appliance is used for the indexing, then there is performance issues as Eclipse has to SSH into the virtual appliance for every artifact in the project, as opposed to building the project when Eclipse SSH's into the virtual appliance once and runs make. So, for performance reasons, Go! includes local cross compilers.

5. Why does Go! use glibc instead of uClibc?

A fundamental philosophy of Go! is to make it feasible to do virtually all embedded Linux device development, including device driver development, in user space. This allows developers to deliver closed source devices, and to retain all their legal rights to the use and distribution of their software. The new fully pre-emptible real time Linux kernel makes it possible to run device drivers in user space with no performance penalty. However, in order to use real-time threads in user space, one needs support for the Native Posix Threads Library (nptl). While uClibc implementations of nptl exist for some architectures, it is not supported, nor part of the normal uClibc distribution at this time. Thus, Go! will use glibc until such time as uClibc officially supports nptl on all of the important CPU architectures (x86, ARM, PowerPC, Mips, Coldfire). The GoEmbedded team also contends that the couple of extra megabytes that glibc takes over uClibc is trivial compared to the resources of the average embedded device today.

Last edited Feb 22, 2010 at 7:28 PM by castone, version 3

Comments

No comments yet.