Support custom run-stage targets

[jschlatow]

Currently, Goa uses base-linux for its run stage. In principle, the tool is able to support other targets like qemu or real hardware. Since run/linux.tcl serves as a blueprint for any future run-target implementation, it should undergo some restructuring. Moreover, we should add a bit of documentation about the limitations of the linux target and how custom targets can be added.

[jschlatow]

I just pushed a commit series to my target_support branch. By restructuring the linux.tcl, I addressed aspects from #31, #34. The simplification of the file should clear the way for #32.

@nfeske @ssumpf I'd appreciate any feedback on my changes. The main commit is 41591b6. Note that the new goa help targets provides the corresponding documentation.

[ssumpf]

@jschlatow: I like the only using config variables as globals approach and the way linux.tcl evolves. Looks good to me, I will try it out tomorrow and have a more profound look.

[nfeske]

@jschlatow I very much appreciate where you are taking Goa. I had not spent much thought on the linux.tcl part in the first place, and all subsequent changes where feature additions following my initial ad-hoc patterns. Now you replaced plenty of duct tape and a bunch of bolts by proper screws. Thank you!

BTW, I have to steal this reference-syntax convention for upvar arguments. I have never seen it before but it makes so much sense.

[jschlatow]

@ssumpf I just pushed commit cbb80e1 that fixes a few issues I discovered today while testing the new implementation with a wider range of scenarios.

[ssumpf]

@ssumpf I just pushed commit cbb80e1 that fixes a few issues I discovered today while testing the new implementation with a wider range of scenarios.

@jschlatow: Tested with the examples. Works as advertised. If I have some spare time, I will test dhewm3 since it uses networking, gui, gpu, etc. I also like the upvar approach, had to do some research, but it looks way better than the global everywhere.

[jschlatow]

Thanks for your feedback. Im glad both of you like it. I just pushed the commits to the official staging branch.

[jschlatow]

@nfeske I just gave your Goa unix tutorial a spin with the recent changes. The first part fails because it's runtime file lacks <requires> <timer/> </requires>. The other parts state this requirement on the other hand.

I am aware that Sculpt always adds a route to parent for the Timer service. In Goa, I decided to only instantiate the timer component and a route if it is explicitly mentioned in the runtime file. My intuition was to make the runtime files more consistent. Most of them state the timer requirement but some don't, yet they still magically work, which I find confusing. Do you support this decision or would you rather prefer we mimic Sculpt's behaviour?

[nfeske]

It's perfectly fine to reinforce stricter <requires> requirements in Goa. My decision of allowing the timer by default was just pragmatism. In the future, it might actually be nice to drop this implicit permission, e.g. to deliberately disallow the notion of "timing" from a subsystem. (as a measure to raise the bar for covert timing channels, or to foster the deliberate determinism of a subsystem)

Regarding the Goa-Unix tutorial, it would be nice to take the error message (due to the missing timer) as opportunity to introduce the <requires> node in the first place (I guess somewhere in 2019-12-13-goa-unix-bash.txt). I'll have to check where it would fit in. Alternatively, I'm of course open for a suggestion from you.

[jschlatow]

I think the best spot to introduce the <requires> node in 2019-12-13-goa-unix-bash.txt is right after adding the <config> because goa run will complain about the services that are mentioned in <parent-provides> but not in <requires>.

[nfeske]

I just noticed that you also added the detection for <requires> <rm/> </requires>. I would leave this out because I think that the RM service should eventually be consolidated into the PD session. The hard-to-explain purpose of the RM session is just a technical detail that we should better not put in front of each Goa user.

[nfeske]

I have adjusted the article in nfeske/genodian@b12c3d4 now.

[jschlatow]

I just noticed that you also added the detection for <requires> <rm/> </requires>. I would leave this out because I think that the RM service should eventually be consolidated into the PD session. The hard-to-explain purpose of the RM session is just a technical detail that we should better not put in front of each Goa user.

Fixed by ef26628