나름 친절한 노스이스턴 대학교의 가이드
directory structure
Threads
•
base kernel을 위한 코드. project 1을 위해선 여기 코드 먼저 고쳐야할거다
userprog
•
user program loader를 위한 코드. project2를 위해선 여길 먼저 고쳐야할거다.
vm
•
거의 빈 디렉토리이다. virtual memory를 구현해야한다. project 3을 위해서
filesys
•
basic file system을 위한 소스코드이다. 이 파일 시스템을 project 2를 위해 사용할거다. 다만 project 4까지는 안 고칠 예정이다.
devices
•
I/O device interfacing을 위한 코드이다. keyboard, timer, disk 등등. timer 구현을 project1에서 하게 될꺼다. 그거 외엔 다른거 고칠거 없다
lib
•
standard C Libaray의 subset의 구현이다. 여기 있는 코드는 Pintos kernel과 함께 컴파일 되며, project 2에서 시작하는 유저 프로그램에 사용될거다. kernel 코드와 user program에서, 여기 있는 헤더들은 #include를 사용해서 포함될거다.
•
여기 있는건 조금만 수정하면 된다.
lib/kernel/
•
C library 의 파트들이고, pintos kernel에만 있는 것들이다. 이건 data type에 대한 구현 또한 포함하고 있는데, kernel code에 대해서는 써도 좋다.
•
bitmaps, doubly linked lists, hash table들이 포함되있음. kernel에는 이 디렉토리에 있는 헤더들이 #include 를 통해 포함되어있다.
lib/user/
•
C library의 parts이며 pintos user programs에만 포함되어있다. 사용자 프로그램에, 이 디렉토리의 헤더가 #include를 통해 포함되어있다.
tests
•
각 프로젝트에 대한 테스트들이다. 이것들은 고쳐도 된다. 만약에 이것들이 제출에 도움이 된다면, 근데 진짜 테스트 전에는 고쳐놔야한다.
examples
•
프로젝트2에서 사용할 user program의 모음이다
misc/, utils/
•
이 파일들은 pintos를 너의 머신에서 작업하기로 결정했다면, 필요한 것들이다. 아니면 무시해도 됨.
Pintos 빌드하기
threads 디렉토리에 들어가서, make 명령어를 쳐라.
이건 threads 밑에 build 폴더를 만들어내고, Makefile과 몇 개의 subdirectores를 이용해서 kernel을 만들어낼거다. 전체 빌드는 30초 내로 걸린다.
Build 디렉토리 안에 생길 파일들이다.
Makefile
•
pintos/src/Makefile.build의 복사본이다. 어떻게 빌드를 하는지 설명되어있다.
kernel.o
•
전체 kernel에 대한 Object 파일이다. 여기에는 debug info도 같이 있기에, GDB 또는 backtrace를 통해 디버깅할 수 있다.
kernel.bin
•
kernel에 대한 메모리 이미지이다. 핀토스 커널을 동작하기 위해 정확한 바이트가 메모리에 로드될거다. ...?
•
Memory image of the kernel, that is, the exact bytes loaded into memory to
run the Pintos kernel. This is just ‘kernel.o’ with debug information stripped
out, which saves a lot of space, which in turn keeps the kernel from bumping
up against a 512 kB size limit imposed by the kernel loader’s design.
loader.bin
•
kernel loader를 위한 메모리 이미지이다. assembly로 이루어진 코드 덩어리인다. 이건 디스크에서 커널을 읽여들어 메모리에서 실행시켜준다. 이건 정확히 512 바이츠의 길이이다.
Build & Test
Test
threads 폴더에서 make check : 통해 이루어짐 (종합적으로 테스트)
→ 이러면 build 폴더에 있는 Makefile을 이용해서 테스트를 쭉 진행함
→ 그리고 build/tests/thread 폴더에 결과가 저장
→ .ouput : 출력 결과를 의미, .result: 패스했는지 안했는지
개별적인 테스트
→ Using your terminal, navigate to the threads build folder and run the following command
→ make check tests/threads/alarm-single.result
→ 이러면 결과가 테스트 폴더에 기록됨
그냥 실행만 보고 싶다
pintos run alarm-multiple
Build
각 lab 폴더에서 make 명령어를 통해 이루어짐
threads 폴더에서 make를 하면 build 폴더가 생성되고 pintos 생성
만약 지우고 싶다. make clean 해줘야함.
수정 후
make clean 후, make check 하거나
make clean 후, make 한 후. threads 폴더에서 make check 하던가
발생 가능한 에러들
•
부팅 실패 : 해결 불가함 (utils 폴더에서 make를 하고 다시 해보자)
◦
여기서 에러가 뜬다
→ Compile the Pintos utilities by typing make in src/utils. Bochs needs squish-pty, VMware Player needs squish-unix. If they don't compile on your recent Linux distribution, comment out #include <stropts.h> in both squish-pty.c and squish-unix.c, and comment out lines 288-293 in squish-pty.c.
GDB
kernel.o를 pintos --gdb -- run alarm-multiple 이용해서 실행
→ build 폴더에서 실행
다른 terminal을 열어서
kernel을 gdb로 조사하면 됨 → pintos-gdb kernel.o
그리고 나면 target을 localhost:1234로 설정 → target remote localhost:1234
QEMU
•
일단 모른다. project2 할 때 되면 하자
팁?
Debugging versus Testing
????????? 뭔소리냐
When you’re debugging code, it’s useful to be able to run a program twice and have it do
exactly the same thing. On second and later runs, you can make new observations without
having to discard or verify your old observations. This property is called “reproducibility.”
One of the simulators that Pintos supports, Bochs, can be set up for reproducibility, and
that’s the way that pintos invokes it by default.
Of course, a simulation can only be reproducible from one run to the next if its input
is the same each time. For simulating an entire computer, as we do, this means that every
part of the computer must be the same. For example, you must use the same command-line
argument, the same disks, the same version of Bochs, and you must not hit any keys on the
keyboard (because you could not be sure to hit them at exactly the same point each time)
during the runs.
While reproducibility is useful for debugging, it is a problem for testing thread synchronization, an important part of most of the projects. In particular, when Bochs is set up for
reproducibility, timer interrupts will come at perfectly reproducible points, and therefore
so will thread switches. That means that running the same test several times doesn’t give
you any greater confidence in your code’s correctness than does running it only once.
So, to make your code easier to test, we’ve added a feature, called “jitter,” to Bochs,
that makes timer interrupts come at random intervals, but in a perfectly predictable way.
In particular, if you invoke pintos with the option ‘-j seed’, timer interrupts will come at
irregularly spaced intervals. Within a single seed value, execution will still be reproducible,
Chapter 1: Introduction 5
but timer behavior will change as seed is varied. Thus, for the highest degree of confidence
you should test your code with many seed values.
On the other hand, when Bochs runs in reproducible mode, timings are not realistic,
meaning that a “one-second” delay may be much shorter or even much longer than one
second. You can invoke pintos with a different option, ‘-r’, to set up Bochs for realistic
timings, in which a one-second delay should take approximately one second of real time.
Simulation in real-time mode is not reproducible, and options ‘-j’ and ‘-r’ are mutually
exclusive.
The QEMU simulator is available as an alternative to Bochs (use ‘--qemu’ when invoking
pintos). The QEMU simulator is much faster than Bochs, but it only supports real-time
simulation and does not have a reproducible mode.
Grading
Testing
make check를 통해서 project를 체크해라
Project1에 대해서는 Boschs에서 실행하는게 빠를거다. 다른 프로그램은 QEMU에서 해라.
make check는 더 빠른 시뮬레이터를 디폴트로 설정하지만, 그 선택을 override할 수 있다.
make check SIMULATOR=--boschs
make check SIMULATOR=--qemu
JavaScript
복사
기본적으로 각 테스트는 완료 시에만 feedback을 준다. 근데 만약에 테스트 과정을 보고 싶다면 VERBOSE=1을 옵션으로 붙여라
make check VERBOSE=1
make check PINTOSOPTS='-j 1' // jitter value를 1로 설정
JavaScript
복사
Design 항목들
1.
Data Structures
2.
Algorithms
3.
Synchronization
4.
Rationale
