xv6 | xv6 - my fork of MIT 's xv6 unix system

To answer your last question, the "=r" (eflags) part is the way in which one specifies in GCC inline assembly¹ what variable to use with a storage "location" and in what manner (https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html). Locations are numbered from 0, and multiple locations can be specified. %0 hence being the first one.

pushfl pushes the contents of the EFLAGS register onto the stack, and pop %0 removes the topmost value, i.e. the EFLAGS value and places it in location %0, which would be the eflags variable. It is done this way, because the IA-32 instruction set does not contain an instruction to read EFLAGS directly.

1: also used by LLVM, but not MSVC – inline assembly is not standardized!

I've learned this solution from somebody named Amrollahi.
Try these steps, if your current step works, don't try the rest of it.

Some mistakes in your kernel code:

• Your system call is not correctly defined: its parameters prototype should be (void)
• Your parameter reading is wrong: you must read the first parameter: argptr( 0, ...

When dealing with paging the golden rule is "never store physical addresses in any kind of pointer". The reasons are:

a) They aren't virtual addresses and can't be dereferenced, so it's better to make bugs obvious by ensuring you get compile time errors if you try to use a physical address as a pointer.

b) In some cases physical addresses are a different size to virtual addresses (e.g. "PAE paging" in 80x86 where virtual addresses are still 32-bit but physical addresses are potentially up to 52 bits); and it's better (for portability - e.g. so that PAE support can be added to XV6 easier at some point).

With this in mind your first line of code is an obvious bug (it breaks the "golden rule"). It should either be pde_t physPgDir = V2P(p->pgdir); or pde_t * pgDir = p->pgdir;. I'll let you figure out which (as I suspect it's homework, and I'm confident that by adhering to the "golden rule" you'll solve your own problem).

You need to install the package containing qemu-system-i386. After a little search on https://packages.ubuntu.com, you can find the right package: qemu-system-x86.

To install the missing package, type

Let's just talk about sleep. In one of your earlier questions, you posted a link to the user.h header file. That header file tells your C compiler what arguments the function takes and what the function returns, on this line:

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.

There's a system call that receives some coordinates to save for another system call to use. How and where to I actually store these coordinates (Two int values).

You can create a new pair of static variables, you can find some examples of such in kernel, for instance struct superblock sb; in fs.c, or int nextpid = 1; in proc.c

So in your case, you can have something like:

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