Test suite

[angrave]

Would be v. useful to have a complete set of C examples for system testing, so that when a new version of jor1k is deployed we don't break stuff.

fork-exec-wait (with wait macros).
pthread
mutex lock
semaphore example
condition variables example
file io (write & printf scanf)

Most of the time we break things due to missing includes - so we should be able to at least compile them with common includes.

[coltonmercurio]

I have completed an inital attempt at this test suite. However, I do not know how you want to integrate this into the cs-education organization. The completed tests are here: https://github.com/cmercur2/systests

[angrave]

Should it be in a subdirectory of sysbuild?

• Lawrence

[coltonmercurio]

I don't think it should be since we could utilize the new GitHub utility if it lives as its own repo. Clone, build, execute.
What are your thoughts?

[angrave]

Please explain further. I don't grok the need for a separate repo
(different release schedules / independent branches / independent teams).
Instead I see a more natural split:

1. VM in the browser foundation + service components
2. Sysprogramming Learning.

I'm a little confused why we cant include these tests as part of the
standard build & deployment process ofthe system programming web app.

• Many projects include their tests in the same repo.

Or part of the emulator build repo.
They seem to be as much part of the rest of the (system
programming-specific) app as anything else.
e.g. should one be able to remote mount/download &run a remote
zip/filesystem with all of these tests inside?

L.

On 4/29/16 11:45 PM, Colton Mercurio wrote:

I don't think it should be since we could utilize the new GitHub
utility if it lives as its own repo. Clone, build, execute.
What are your thoughts?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cs-2Deducation_sysbuild_issues_113-23issuecomment-2D215936988&d=CwMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=DvT4PEagC1_uJoK7XYcVznCf9vBnV8AqDdM20MaTLvM&m=l_UPPWuM2o01r5ubzC20o_H16-XevkPDFOaHD2msJes&s=TzJZ-royB8uHZyJ4zVmNx0dIpLVQmG79lTHgBJvViJw&e=

[coltonmercurio]

There are many solutions in hosting these tests.

• These test exist in their own repo. We can use the github integration that was recently added to clone this repo from outside the VM. Benefits are that it does not rely on any system functionalities of the VM to load the tests onto the VM. Downside, is that it is yet another repo that must be managed among the 5 others related to this project.
• Downloading a zip from the sysassets gh-pages repo (include a zipped version in the repo). This does not create another repo but, a potential headache would be that we would have to re-zip the tests every time we a change. We could download via curl/wget from within the VM or click-and-drag from desktop to the file browser.
• Sparse cloning from within the VM from sysassets. This depends on the networking functionality of the VM, which may or may not be broken at the time of testing.
• Including it in the sysassets jor1k file system, so they are present on boot. The only downside to this is that we would have to modify fs.json for every test added.

I think it all comes down to your preference.

[neelabhg]

I'm in favor of having these tests in the sysbuild repo. The tests should be run in CI, in a completely automated fashion.