search

genodelabs / goa

Tool for streamlining the development of Genode applications
GNU Affero General Public License v3.0
19 stars 17 forks source link

Support custom run-stage targets #44

Closed jschlatow closed 1 year ago

jschlatow commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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

jschlatow commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

I have adjusted the article in https://github.com/nfeske/genodian/commit/b12c3d41c6af559cc309cf0fd6030b8b91e2bf02 now.

jschlatow commented 1 year ago

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