xv6-riscv | dennis ritchie 's and ken thompson

I don't think the noreturn attribute is strictly required, but it helps.

The noreturn attribute tells the compiler that the exit function will never return. In theory, this allows the compiler to better understand the possible code paths of any code that calls exit, so it can display more accurate warnings and optimize the code better.

It was added in this commit probably because user.h uses the struct stat * datatype

This is literally the code that was so confusing that its original authors wrote "You are not expected to understand this" in the comments, so don't feel bad for not understanding it.

The key thing you may have missed is that p->context contains an address where swtch is to resume execution of process p. It's set up, for instance, here:

This has been mentioned in Tools Used in 6.S081

At this moment in time, it seems that the package qemu-system-misc has received an update that breaks its compatibility with our kernel. If you run make qemu and the script appears to hang after

Edit: A quick google of "qemu timebase riscv mtime" found a google groups chat which states that RDTIME is nanoseconds since boot and mtime is an emulated 10Mhz clock.

I haven't done a search to find the information you need, but I think I have some contextual information that would help you find it. I would recommend searching QEMU documentation / code (probably from Github search)for how mtime and mtimecmp work.

In section 10.1 (Counter - Base Counter and Timers) of specification¹, it is explained that the RDTIME psuedo-instruction should have some fixed tick rate that can be determined based on the implementation ². That tick rate would also be shared for mtimecmp and mtime as defined in the privileged specification ³.

I would presume the ticks used be the sleep system call would be the same as these ticks from the specifications. In that case, xv6 is just a kernel and wouldn't then define how many ticks/second there are. It seems that xv6 is made to run on top of qemu so the definition of ticks/second should be defined somewhere in the qemu code and might be documented.

From the old wiki for QEMU-riscv it should be clear that the SiFive CLINT defines the features xv6 needs to work, but I doubt that it specifies how to know the tickrate. Spike also supports the CLINT interface so it may also be instructive to search for the code in spike that handles it.

¹ I used version 20191213 of the unprivileged specification as a reference

²

The RDTIME pseudoinstruction reads the low XLEN bits of the time CSR, which counts wall-clock real time that has passed from an arbitrary start time in the past. RDTIMEH is an RV32I-only in- struction that reads bits 63–32 of the same real-time counter. The underlying 64-bit counter should never overflow in practice. The execution environment should provide a means of determining the period of the real-time counter (seconds/tick). The period must be constant. The real-time clocks of all harts in a single user application should be synchronized to within one tick of the real-time clock. The environment should provide a means to determine the accuracy of the clock.

³

3.1.10 Machine Timer Registers (mtime and mtimecmp) Platforms provide a real-time counter, exposed as a memory-mapped machine-mode read-write register, mtime. mtime must run at constant frequency, and the platform must provide a mechanism for determining the timebase of mtime.