1

My setup

I have a windows 10 PC and on that I have an ubuntu 18.04 virtualbox (+ guest editions) and its all working well.

I use the ubuntu VM to develop our C++ code, all the tools and gcc etc working nicely. However we use IBMs Rhapsody to generate some state machine code - probably that was a mistake, but we are too far down the path to want to stop using it now, and its a good state machine tool - but a crappy IDE!.

Rhapsody runs well on windows, but is only supported by redhat version 6 32-bit. I am working on getting it working on newer versions and 64-bit - but that is a background task at the moment.

What I need is a quick way to generate our state code and integrate it with the rest of the project. Here is what I have in mind:

  • On windows draw the state machine with rhapsody and generate code-> .../project/autogen/ all the rhapsody code is put into one folder called autogen.
  • On the ubuntu VM build the project .../project/> make

But this requires the VM folder and the windows folder to be shared. So it sounds like I just need to setup a VM share. The issue here is that the folder that is shared is windows-side, and this folder format does not work for linux (git, make, gcc, etc...) since the permissions/types are all wrong (not to mention symlinks).

Our current solution

So at the moment, we have full development environments in both windows and ubuntu. On windows its with visual studio and rhapsody. On Ubuntu with gcc and vscode. Our work flow is like this:

  • On windows: Edit Rhapsody state machines and generate code
  • On windows: Test and debug the state changes
  • On windows: commit changes to git
  • On ubuntu: pull the changes from git
  • On ubuntu: edit other areas of the code, test and debug
  • On ubuntu: push to git
  • On windows: pull from git
  • On windows: re-test changes (debug if required)

We have two jenkins servers (for windows and ubuntu). The overhead of keeping windows side working is getting quit high and time consuming as the code wants to become more linux specific (it is designed to run on embedded linux systems). So there are plenty of #ifdef WIN32 bits of code around - we have a OS abstraction layer etc...

We want to do away with the need to develop on windows.

My idea for a solution

So my idea is that I somehow create a shared folder on the VM which I can open in windows to edit the rhapsody files and generate the autogen code such that:

  • In the VM:
    • I do all the building (gcc, make, etc...)
    • I do all the config control (git)
    • I do all other code/project editing (using vscode, etc...)
  • In the windows host:
    • I just open the rhapsody project, can edit and save it and get it to generate files into the shared project/autogen folder directly on the VM.

So my questions are: 1. Is this feasible 2. Is this possible? - and if so how can I share a folder from the Ubuntu VM so that the windows box can see it?

As I mentioned I am also trying to get Rhapsody working on linux, so far I have got it working on Centos6, but that is so old it is no good. I am working towards centos8 32-bit next and see how far I get, but that could take a while.

Any other suggestion welcome.

7
  • 2
    Samba shares is what I would recommend, creating the share on Ubuntu and configuring the smb.conf to maintain UGO privs and not Windows ACLs (refer to the Samba man pages). On Windows, you'd log in to the share via the Samba username and password you configure on Ubuntu, also ensure the default permissions for newly created files within the share on Windows are rw-rw or rw-r for UG, else you'll end up with newly created files on Windows being created with execute Linux privs (directories should be the normal 755) - which is configured in either the smb.conf or the share's config
    – JW0914
    May 9, 2020 at 11:35
  • oh great! - I was thinking it should be some sort of virtualbox thing, I had not thought of using normal samba! - bit rusty on that but will give that a go :) May 9, 2020 at 12:05
  • 1
    An FYI I forgot to mention, in the smb.conf ensure you set min protocol = SMB2, as SMB1 should never be utilized (it should also be completely removed from Windows via WinKey+R > OptionalFeatures > OK > untick SMB 1.0/CIFS... > tick SMB Direct > OK and reboot if necessary)
    – JW0914
    May 9, 2020 at 12:19
  • @JW0914 I will do this, but at the moment I can't even see my VM on the windows "network". If I type \\vm_name I don't see anything. If I ping \\vm_name I don't see it. Then if I ping 10.0.2.15 (the VM NAT IP address) from windows I still don't see it! -so I think I need to raise another question to sort this... :o May 9, 2020 at 14:12
  • That would probably be best, as I'm familiar with Hyper-V, but not VirtualBox... if VB has the ability to create an Internal only network adapter (essentially a vLAN, but not in the Linux sense, as due to the Windows TCP/IP stack, Windows can't create vLANs), else use OpenVPN's TAP-adapter to install a virtual adapter on Windows, then: Adapter Properties > Configure > Advanced > Media Status - Always Connected > OK. Assign this adapter an IP and netmask on the same subnet the VM is using, and that should allow communication if VB is configured to allow such host to client traffic.
    – JW0914
    May 9, 2020 at 15:01

0

You must log in to answer this question.

Browse other questions tagged .