jserv / xv6-x86_64 Goto Github PK

From the specification of x86_64, Vol. 2A 3-191, the cpuid instruction will override register EDX in most cases. A more general solution, declaring this register in clobber list would be better. Furthermore, x86_64 specification only marks EDX as reserved when EAX is 07h, such claim may be violated in the future, to maximize the compatibility, I think declaring the register EDX in clobber list is worth considering.

The source of xv6: kernel/cpuid.c: 140:
asm("cpuid" : "=a"(maxsubleaf), "=b"(sef_flags) : "a" (7), "c" (0) :);

Bring a primitive implementation of a network in xv6. Supported NIC will be NE2000. This implement refers to MINIX.

Reference: https://github.com/s-shin/xv6-network

While building xv6 with clang, tools/sign.pl complains:

$ make CC=clang
...
boot block too large: 894 bytes (max 510)
Makefile:119: recipe for target 'out/bootblock' failed

The version of clang:
$ clang --version
Ubuntu clang version 3.6.0-2ubuntu1 (tags/RELEASE_360/final) (based on LLVM 3.6.0)

With a technique called copy-on-write (COW), when a fork occurs, the parent process's pages are not copied for the child process. Instead, the pages are shared between the child and the parent process. Whenever a process (parent or child) modifies a page, a separate copy of that particular page alone is made for that process (parent or child) which performed the modification. This process will then use the newly copied page rather than the shared one in all future references. The other process (the one which did not modify the shared page) continues to use the original copy of the page (which is now no longer shared). This technique is called copy-on-write since the page is copied when some process writes to it.

Initial implementation: https://github.com/delphifirst/xv6/commits/master

initial implementation:

• https://github.com/amitaid/xv6/commits/assignment-2
• https://github.com/ckumar1/xv6-threads/commits/master
• https://github.com/Jamesjue/xv6_hacks/tree/multiThread

I'm trying to build xv6-x86_64 on Debian testing 64 (gcc 12 is already installed)
Running make xv6.img yield this:

No rule to make target /.d
gcc -fno-builtin -fno-pic -m32 -nostdinc -Iinclude -Os -o out/bootmain.o -c kernel/bootmain.c
gcc -fno-builtin -fno-pic -m32 -nostdinc -Iinclude -o out/bootasm.o -c kernel/bootasm.S
ld -m elf_i386 -nodefaultlibs --omagic -e start -Ttext 0x7C00
-o out/bootblock.o out/bootasm.o out/bootmain.o
ld: Error: unable to disambiguate: -nodefaultlibs (did you mean --nodefaultlibs ?)
make: *** [Makefile:137: out/bootblock] Error 1

POSIX semaphores allow processes and threads to synchronize their actions.

A semaphore is an integer whose value is never allowed to fall below zero. Two operations can be performed on semaphores: increment the semaphore value by one (sem_post); and decrement the semaphore value by one (sem_wait). If the value of a semaphore is currently zero, then a sem_wait operation will block until the value becomes greater than zero.

POSIX semaphores come in two forms: named semaphores and unnamed semaphores.

Initial implementation: https://github.com/MrHohn/cs518hw2/commits/sp15-hw2

Using make OPT=-O1 specifies the optimization order of gcc. However, it always fails for O=1, 2, and s.

The case of -O1:

• build FAIL

nmeta 29 (boot, super, inode blocks 26, bitmap blocks 1) blocks 941 log 30 total 1000
mkfs: tools/mkfs.c:268: iappend: Assertion `fbn < (10 + (512 / sizeof(uint)))' failed.
Makefile:221: recipe for target 'fs.img' failed

The case of -O2:

• build FAIL

nmeta 29 (boot, super, inode blocks 26, bitmap blocks 1) blocks 941 log 30 total 1000
mkfs: tools/mkfs.c:268: iappend: Assertion `fbn < (10 + (512 / sizeof(uint)))' failed.
Makefile:221: recipe for target 'fs.img' failed

The case of -Os:

• build OK
• usertests hangs:

...
open small succeeded ok
read succeeded ok
small file test ok
big files test

user/sh.c:58:1: error: infinite recursion detected [-Werror=infinite-recursion]

   58 | runcmd(struct cmd *cmd)
      | ^~~~~~

user/sh.c:89:5: note: recursive call

   89 |     runcmd(rcmd->cmd);

      |     ^~~~~~~~~~~~~~~~~

user/sh.c:109:7: note: recursive call

  109 |       runcmd(pcmd->left);

      |       ^~~~~~~~~~~~~~~~~~

user/sh.c:116:7: note: recursive call

  116 |       runcmd(pcmd->right);

      |       ^~~~~~~~~~~~~~~~~~~

user/sh.c:95:7: note: recursive call

   95 |       runcmd(lcmd->left);

      |       ^~~~~~~~~~~~~~~~~~

user/sh.c:97:5: note: recursive call

   97 |     runcmd(lcmd->right);

      |     ^~~~~~~~~~~~~~~~~~~

user/sh.c:127:7: note: recursive call

  127 |       runcmd(bcmd->cmd);

      |

could I replace sh?