ASST2.1 Changes; Multipart Targets

(Scott Haseley) #1

Everything is set up so you can start submitting ASST2.1, but there a couple things you need to do first, and a one thing you that is new this semester that you need to be aware of.

ASST2.1 Changes
We’ve made some changes to the /testbin/consoletest, which is the test you need to pass for ASST2.1. This change also required a test161 change. So, you’ll need to:

  1. Merge the latest OS/161 upstream staff changes. There was a previous forum post explaining how to do this.
  2. Update test161 to version 1.3.1. There was also a previous forum post on how to update test161.

Since there are changes to consoletest, that test needs to be recompiled and installed. The easiest way to accomplish this is by running bmake && bmake install from the top of your source directory.

Multipart Targets and Submitting ASST2.1

This year, ASST2 and ASST3 have been broken into multiple subtargets. For ASST2, you will be submitting ASST2.1 and ASST2.2. The testing and submission process is the same as ASST1. For ASST2.1, you can test using

test161 run asst2.1

and submit with

test161 submit asst2.1

The difference is, you will also receive a score for ASST2, which is made up of ASST2.1 and ASST2.2. The ASST2 metatarget is cumulative, and is what we use for the leaderboard.

For ASST2, the point breakdown is 20 points (ASST2.1) and 130 points (ASST2.2). When you submit ASST2.1, you will see an entry on for both ASST2.1 (out of 20) and ASST2 (out of 150).

Good luck on ASST2!

20 Feb 2017: ASST2.1
no previous prototype for 'snsecprintf'
(Abishek Ramasubramanian) #2

So my partner and I are facing an issue running the kernel after this update. On running sys161 kernel, it prints the following errors:

…/…/…/common/libtest161/test161.c:91:1: error: no previous prototype for ‘snsecprintf’ [-Werror=missing-prototypes]
snsecprintf(size_t len, char *buffer, const char *secret, const char *msg, const char *name)
cc1: all warnings being treated as errors
*** Error code 1

bmake[2]: stopped in /home/argon/os161/userland/lib/libtest161
*** Error code 1

bmake[1]: stopped in /home/argon/os161/userland/lib
*** Error code 1

bmake: stopped in /home/argon/os161/userland
sys161: System/161 release 2.0.8, compiled Jan 9 2017 17:17:19

And on running test161 run asst2.1, it shows the following error:

Unable to execute command: test161 cannot determine your root directory from the CWD.

We’ve checked our test161 version, and it is 1.3.1, as expected. This is how we are compiling our userland directory:

cd ~/os161/userland
bmake && bmake install

Could someone point out where we’re going wrong?

no previous prototype for 'snsecprintf'
(Scott Haseley) #3

It looks like it isn’t seeing the header file change with a new function we’ve added. At first I thought you might need to do bmake clean first, but I see you are running this from userland. What happens if you build from your ~/os161/ directory? (BTW, you should be building the userspace binaries from the top of the source tree, not from userland/.)

(Alex J Barganier) #4

I had this same issue when I tried recompiling consoletest, @shaseley is right I think. Doing a bmake clean && bmake && bmake install in ~/os161/ fixed the problem for me.

(Abishek Ramasubramanian) #5

@shaseley We’re using a script to configure and install the kernel. The commands used are as follows:

cd ~/os161/kern/conf
./config ASST2
cd …/compile/ASST2
bmake clean && bmake depend && bmake && bmake install
cd ~/os161/userland
bmake && bmake install
cd ~/root
sys161 kernel

Is there something wrong in the above script?

(Scott Haseley) #6

You shouldn’t run bmake from userland. Replace

cd ~/os161/userland


cd ~/os161

FWIW you should rarely need to do the clean step, as it defeats one of the features of using make/bmake. But, the kernel builds fast enough that it doesn’t really matter. I suggested the clean because it looked like it didn’t automatically pull the new test161.h file during the build. However, I duplicated your situation by building from userland instead of the top of the source tree (~/os161 in your case). If you would have originally built from the right directory, I think this would have been avoided (at least it was for me during testing).

(Abishek Ramasubramanian) #7

Thanks, @shaseley! That did it!