HUST operating system lab
1.0.0
Ce projet provient du référentiel 华中科技大学操作系统团队 / RISCV-PKE.
Comme vous pouvez le voir dans les branches , chaque branche correspond à un niveau avec sa description concise.
Ce n'est pas un package exécutable local, car je n'ai pas fait de compilation. Considérez-le simplement comme un livre de réponses de points de contrôle dans l'évaluation en ligne EducOder . Si vous souhaitez exécuter ce projet localement, veuillez lire la suite et trouver votre chemin dans ReadMe officiel .
Cette préface ne sera affichée que dans la branche par défaut.
Les documents en chinois peuvent être trouvés ici. Il n'y a toujours pas encore de documents dédiés en anglais, mais les commentaires en ligne dans nos codes ainsi que les noms auto-exploitants pour les variables et les fonctions aideront votre voyage de PKE.
PKE est un projet open source (voir Licence.txt pour les informations de licence) à l'objectif éducatif des cours d'ingénierie du système d'exploitation / d'ingénierie du système informatique, donné aux étudiants de premier cycle spécialisés en CS (informatique) ou EECS (génie électrique et informatique) dans les universités.
PKE fournit une série de laboratoires qui couvrent les points de connaissance de l'ingénierie du système d'exploitation ainsi qu'une partie de l'organisation / architecture informatique, notamment:
LAB1 (3 Labs de base + 2 Labs de défi): pièges (systèmes), exceptions et interruptions (IRQS en terminologie Intel).
LAB2 (3 Labs de base + 2 Labs Challenge): Gestion de la mémoire.
Lab3 (3 Labs de base + 2 Labs de défi): processus.
Lab4 (3 Labs de base): périphérique et fichier (réalisé sur une carte PYNQ FPGA + une voiture de jouets Arduino).
Les expériences dans le repo peuvent être différentes (avec plus de laboratoires réels) de la liste ci-dessus avec le temps qui passe.
De l'angle de l'éducation sur l'ingénierie du système d'exploitation, différent de nombreux projets éducatifs de système d'exploitation célèbres (comme XV6 (JOS quand plus tôt) utilisés dans le MIT 6.828 et UCore enseignés à l'Université de Tsinghua) qui utilisent des noyaux OS complète ou presque complets contenant presque tout comme la gestion des processus, les systèmes de fichiers et de nombreux autres modules, PKE n'est pas un grain de système d'exploitation complet (en fait, PKE ne jamais être l'un des autres.) .
PKE est construit autour de l'idée du noyau proxy (proposé dans PK, un projet open source de l'écologie du logiciel RISC-V), qui met l'accent sur la construction d'un noyau de système d'exploitation "juste tout juste" pour une application donnée. Avec une telle idée, nous concevons une série de laboratoires dans PKE qui "améliore" le noyau OS en donnant un ensemble d'applications, de simple à complexe. Au cours des mises à niveau, vous pouvez apprendre de plus en plus d'idées sophistiquées des systèmes d'exploitation modernes, et plus important encore, jouer avec eux en suivant les laboratoires, l'un après l'autre.
Dans chaque laboratoire, PKE commence par une application (placée dans le dossier ./user/ , avec le préfixe "App_") et un noyau de système d'exploitation proxy incomplet . Pendant le laboratoire, vous avez besoin de comprendre l'interaction entre l'application et le noyau de système d'exploitation proxy (parfois, aussi la machine RISC-V émulée en utilisant Spike, ou une carte FPGA avec un noyau RISC-V doux); 2) Suivez le code de l'application donnée au noyau OS en fonction de la compréhension; 3) Complétez le noyau OS proxy pour que l'application (ou le système) s'exécute correctement et en douceur.
Dans les laboratoires de PKE, nous avons fait de notre mieux pour contrôler et minimiser l'échelle de code de chaque laboratoire, dans l'espoir de vous aider à rester concentré sur les composants clés du système d'exploitation, et à minimiser les efforts en même temps. Contactez-nous si vous avez d'autres suggestions sur la réduction de l'échelle de code, merci d'avance!
1. Installer le système d'exploitation (machine virtuelle ou subversion Windows Linux)
(préféré) Ubuntu 16.04lts ou plus, 64 bits
2. Installez des outils pour construire un compilateur croisé et un émluateur
$ sudo apt-get install autoconf automake autotools-dev curl python3 libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex3. Installer RISC-V CROSS-COMPILER
$ export RISCV=/path-to-install-RISCV-toolchains
$ git clone --recursive https://github.com/riscv/riscv-gnu-toolchain.git
$ cd riscv-gnu-toolchain
$ ./configure --prefix= $RISCV
$ make -j $( nproc )
$ sudo make installDans les commandes ci-dessus, $ (nproc) représente le nombre de threads que vous souhaitez invoquer pendant la construction. Genelly, $ (nproc) devrait être égal au nombre de cœurs que votre ordinateur dispose. Après cette étape, vous devriez trouver des exécutables, comme RISCV64-Sundown-Elf-GCC, RISCV64-UNDOWN-ELF-GDB, RISCV64-SUNDOWN-ELF-OBJDUmp, et bien d'autres (avec le préfixe de nom de "RISCV64-Sunknown-Elf-") dans votre / path-to-instal-risv-toolchains / bin Directory.
4. Installer l'émulateur (Spike)
$ sudo apt-get install device-tree-compiler
$ git clone https://github.com/riscv/riscv-isa-sim.git
$ cd riscv-isa-sim
$ mkdir build
$ cd build
$ ../configure --prefix= $RISCV
$ make -j $( nproc )
$ sudo make installAprès cette étape, vous devriez trouver des exécutables comme Spike, Spike-Dasm dans votre répertoire / path-to-stall-riscv-toolchains / bin .
5. Clone PKE Repo
$ git clone https://github.com/MrShawCode/riscv-pke.gitAprès cette étape, vous aurez le répertoire PKE contenant les laboratoires PKE.
6. Construire / exécuter PKE
$ make [run]7. (Facultatif) Installer OpenOCD pour le débogage
$ git clone https://github.com/riscv/riscv-openocd.git
$ cd openocd
$ ./bootstrap (when building from the git repository)
$ ./configure --prefix= $RISCV
$ make -j $( nproc )
$ sudo make install Après avoir installé OpenOCD, vous pouvez déboguer le noyau PKE. Utilisez simplement la commande suivante:
$ make gdbDans ce laboratoire, nous allons apprendre les tamis de base de TRAP (également appelés syscall dans de nombreux manuels).
Un piège (par exemple, printf qui est dans notre utilisation quotidienne) est généralement émis par une application et géré par le noyau. Il est très important pour un système d'exploitation de fournir une telle installation, car les applications exécutées dans des modes moins privilégiés (par exemple, mode utilisateur dans RISC-V) doivent effectuer fréquemment des opérations juridiques comme les E / O qui doivent être menées dans des modes de privilège plus élevés (par exemple, superviseur ou modes de machine dans RISC-V).
Lab1_1 donne une application dans "User / Lab1_1_Helloworld.c", dont la fonction principale () appelle une fonction printU qui a la même fonctionnalité que printf , mais sous un nom légèrement différent. printU est défini dans "User / DO_print.c" et invoque en fait le piège par l'instruction ECALL (voir les assemblages en ligne dans la fonction de DO_USER_PRINT ).
La structure de LAB1_1 est répertoriée dans les éléments suivants:
.
├── LICENSE.txt
├── Makefile
├── README.md
├── .spike.cfg
├── kernel
│ ├── config.h
│ ├── elf.c
│ ├── elf.h
│ ├── kernel.c
│ ├── kernel.lds
│ ├── machine
│ │ ├── mentry.S
│ │ └── minit.c
│ ├── process.c
│ ├── process.h
│ ├── riscv.h
│ ├── strap.c
│ ├── strap.h
│ ├── strap_vector.S
│ ├── syscall.c
│ └── syscall.h
├── spike_interface
│ ├── atomic.h
│ ├── dts_parse.c
│ ├── dts_parse.h
│ ├── spike_file.c
│ ├── spike_file.h
│ ├── spike_htif.c
│ ├── spike_htif.h
│ ├── spike_memory.c
│ ├── spike_memory.h
│ ├── spike_utils.c
│ └── spike_utils.h
├── user
│ ├── app_helloworld.c
│ ├── user.lds
│ ├── user_lib.c
│ └── user_lib.h
└── util
├── functions.h
├── load_store.S
├── snprintf.c
├── snprintf.h
├── string.c
├── string.h
└── types.h
Le répertoire racine contient principalement les documents (c'est-à-dire les fichiers MD), le texte de licence et, surtout, le fichier Make (nommé comme MakeFile ). Le sous-répertoire du noyau contient le noyau OS, tandis que le sous-répertoire utilisateur contient l'application donnée (dans App_Helloworld.c ) ainsi que les fichiers de code source contenant les roulements de prise en charge, qui doivent être placés dans la bibliothèque d'utilisateurs dans le système d'exploitation complet comme Linux.
Pour comprendre le noyau PKE OS (de LAB1_1) et accomplir le laboratoire, vous devez commencer à partir de l'application donnée. Par conséquent, nous commençons le tourisme à partir de l'utilisateur / app_helloworld.c :
1 /*
2 * Below is the given application for lab1_1.
3 *
4 * You can build this app (as well as our PKE OS kernel) by command:
5 * $ make
6 *
7 * Or run this app (with the support from PKE OS kernel) by command:
8 * $ make run
9 */
10
11 #include " user_lib . h "
12
13 int main ( void ) {
14 printu ( "Hello world!n" );
15
16 exit ( 0 );
17 }À partir du code, nous pouvons observer qu'il existe une fonction nouvellement définie appelée printU , dont la fonctionnalité est équipée de printf de notre utilisation quotidienne. La raison pour laquelle nous définissons une nouvelle fonction au lieu d'utiliser PRINTF est que PRINTF est déjà défini dans le Newlib de la chaîne d'outils transformant RISC-V.
Le prototype et l'implémentation de PrintU se trouvent respectivement dans user / user.h et user / do_print.c .
Après avoir terminé un laboratoire (et commis votre solution), vous pouvez continuer la pratique des laboratoires suivants. Par exemple, après avoir terminé LAB1_1, vous pouvez commettre votre solution par:
$ git commit -a -m " your comments to lab1_1 "Ensuite, passez au laboratoire suivant (Lab1_2) par:
$ git checkout lab1_2_exceptionet fusionner votre solution dans le laboratoire précédent par:
$ git merge lab1_1_syscall -m " continue lab1_2 "Après tout cela, vous pouvez continuer à travailler sur LAB1_2.
Remarque : Ne fusionnez jamais Challenge Labs, tels que Lab1_Challenge1_Backtrace, Lab2_Challenge1_PageFaults, etc.
C'est tout. J'espère que vous apprécierez!
