occupymars2025 / xv6-labs-2023-deprecated Goto Github PK

Home Page: https://pdos.csail.mit.edu/6.1810/2023/index.html

License: Other

Emacs Lisp 0.03% Makefile 2.87% Python 7.46% C 86.43% Assembly 2.95% Perl 0.22% Shell 0.03%

xv6-labs-2023-deprecated's Introduction

# round 2: https://pdos.csail.mit.edu/6.1810/2023/schedule.html
- [ ] (2024/2/2)sep 6: LEC 1 (rtm): Introduction and examples (handouts: xv6 book)


# [branch 'util' is for 'Lab: Xv6 and Unix utilities'](https://pdos.csail.mit.edu/6.1810/2023/labs/util.html)

xv6 is a re-implementation of Dennis Ritchie's and Ken Thompson's Unix
Version 6 (v6).  xv6 loosely follows the structure and style of v6,
but is implemented for a modern RISC-V multiprocessor using ANSI C.

ACKNOWLEDGMENTS

xv6 is inspired by John Lions's Commentary on UNIX 6th Edition (Peer
to Peer Communications; ISBN: 1-57398-013-7; 1st edition (June 14,
2000)).  See also https://pdos.csail.mit.edu/6.1810/, which provides
pointers to on-line resources for v6.

The following people have made contributions: Russ Cox (context switching,
locking), Cliff Frey (MP), Xiao Yu (MP), Nickolai Zeldovich, and Austin
Clements.

We are also grateful for the bug reports and patches contributed by
Takahiro Aoyagi, Silas Boyd-Wickizer, Anton Burtsev, carlclone, Ian
Chen, Dan Cross, Cody Cutler, Mike CAT, Tej Chajed, Asami Doi,
eyalz800, Nelson Elhage, Saar Ettinger, Alice Ferrazzi, Nathaniel
Filardo, flespark, Peter Froehlich, Yakir Goaron, Shivam Handa, Matt
Harvey, Bryan Henry, jaichenhengjie, Jim Huang, Matúš Jókay, John
Jolly, Alexander Kapshuk, Anders Kaseorg, kehao95, Wolfgang Keller,
Jungwoo Kim, Jonathan Kimmitt, Eddie Kohler, Vadim Kolontsov, Austin
Liew, l0stman, Pavan Maddamsetti, Imbar Marinescu, Yandong Mao, Matan
Shabtay, Hitoshi Mitake, Carmi Merimovich, Mark Morrissey, mtasm, Joel
Nider, Hayato Ohhashi, OptimisticSide, Harry Porter, Greg Price, Jude
Rich, segfault, Ayan Shafqat, Eldar Sehayek, Yongming Shen, Fumiya
Shigemitsu, Cam Tenny, tyfkda, Warren Toomey, Stephen Tu, Rafael Ubal,
Amane Uehara, Pablo Ventura, Xi Wang, WaheedHafez, Keiichi Watanabe,
Nicolas Wolovick, wxdao, Grant Wu, Jindong Zhang, Icenowy Zheng,
ZhUyU1997, and Zou Chang Wei.


The code in the files that constitute xv6 is
Copyright 2006-2022 Frans Kaashoek, Robert Morris, and Russ Cox.

ERROR REPORTS

Please send errors and suggestions to Frans Kaashoek and Robert Morris
(kaashoek,[email protected]).  The main purpose of xv6 is as a teaching
operating system for MIT's 6.1810, so we are more interested in
simplifications and clarifications than new features.

BUILDING AND RUNNING XV6

You will need a RISC-V "newlib" tool chain from
https://github.com/riscv/riscv-gnu-toolchain, and qemu compiled for
riscv64-softmmu.  Once they are installed, and in your shell
search path, you can run "make qemu".

xv6-labs-2023-deprecated's People

Contributors

Stargazers

Watchers

xv6-labs-2023-deprecated's Issues

[BUG] in `allocproc(void)`, if `kalloc()` fail to allocate a page for trampoline, then call `freeproc()` which will unmap trampoline, but at this point, trampoline has not been mapped

I think about it when I do the lab 3(pgtbl)

Speed up system calls

my solution to this lab

my possible solution to this bug:

make uvmunmap() able to deal with not-yet-mapped virtual page, NOT just "panic", but I'm not sure if it is OK

Your are wrong! The bug doesn't exit. You should study the source code more carefully

[NOT CLEAR] In mappages(), what if the argument "pa" is in a page accidentally allocated as part of the page table ?

I propose this idea when I study along this path:

kernel/vm.c => `kvmmake(void)` => `kvmmap(kpgtbl, (uint64)etext, (uint64)etext, PHYSTOP-(uint64)etext, PTE_R | PTE_W);`

You need to debug it to clarify it

// the following is my thought, but it seems to be wrong,
// What would happen when the address range [PGROUNDDOWN(pa), PGROUNDDOWN(pa) + size]
// has some pages allocated as pages of the page table ?
// =========== start ============
// Caution: pa must be less than 0x8000_0000, 
// physical memory layout:
// part 1: [0, 0x8000_0000], for all kinds of IO devices
// part 2: [0x8000_0000, end], for the kernel
// part 3: [PGROUNDUP(end), PGROUNDDOWN(PHYSTOP)]
// part 3 is used for kfree() and kalloc()
// see kmem.freelist
// ========== end  ==============

[SOLVED] `(gdb) layout src` , `Undefined command: "layout". Try "help".` gdb "tui" mode not supported

(gdb) tui
Undefined command: "tui".  Try "help".
(gdb) layout
Undefined command: "layout".  Try "help".

solution:

I built the riscv toolchain myself, but my ubuntu lacked some package, so my built gdb binary did not support "tui" mode

~/riscv/bin$ ./riscv64-unknown-elf-gdb -tui
./riscv64-unknown-elf-gdb: TUI mode is not supported

riscvarchive/riscv-binutils-gdb#256

my solution: download the prebuilt binary directly from the official repo:

https://github.com/riscv-collab/riscv-gnu-toolchain/releases/tag/2023.11.22

[TODO]

[SOLVED]

https://pdos.csail.mit.edu/6.1810/2023/labs/util.html

Changes to the file system persist across runs of qemu; to get a clean file system run `make clean` and then `make qemu`.

In my case, `Changes to the file system does NOT persist across runs of qemu`, why? what's the mechanism behind it ?

Solution: yes, it is my case. I'm wrong. Changes to the file system does NOT persist across runs of qemu if you modified the source code

occupymars2025 / xv6-labs-2023-deprecated Goto Github PK

xv6-labs-2023-deprecated's Introduction

xv6-labs-2023-deprecated's People

Contributors

Stargazers

Watchers

xv6-labs-2023-deprecated's Issues

I think about it when I do the lab 3(pgtbl)

my possible solution to this bug:

make uvmunmap() able to deal with not-yet-mapped virtual page, NOT just "panic", but I'm not sure if it is OK

Your are wrong! The bug doesn't exit. You should study the source code more carefully

I propose this idea when I study along this path:

kernel/vm.c => kvmmake(void) => kvmmap(kpgtbl, (uint64)etext, (uint64)etext, PHYSTOP-(uint64)etext, PTE_R | PTE_W);

You need to debug it to clarify it

solution:

I built the riscv toolchain myself, but my ubuntu lacked some package, so my built gdb binary did not support "tui" mode

my solution: download the prebuilt binary directly from the official repo:

[SOLVED]

Changes to the file system persist across runs of qemu; to get a clean file system run make clean and then make qemu.

In my case, Changes to the file system does NOT persist across runs of qemu, why? what's the mechanism behind it ?

Solution: yes, it is my case. I'm wrong. Changes to the file system does NOT persist across runs of qemu if you modified the source code

Recommend Projects

Recommend Topics

Recommend Org

Jobs

kernel/vm.c => `kvmmake(void)` => `kvmmap(kpgtbl, (uint64)etext, (uint64)etext, PHYSTOP-(uint64)etext, PTE_R | PTE_W);`

Changes to the file system persist across runs of qemu; to get a clean file system run `make clean` and then `make qemu`.

In my case, `Changes to the file system does NOT persist across runs of qemu`, why? what's the mechanism behind it ?