 Hi, everyone, it's Jeff Chalon again, and then in the third installment of the screencasts for assignment zero, what I want to do is just look a little bit at the source tree. I'm not going to go into detail here because that's really best for you guys to do on your own, but I want to give you a sense of how to get started and a sense of sort of how to approach some of the questions that are in there for you to look at. So at this point, we've got an environment set up, and in the last episode, we were able to clone and build and install the kernel. So we're in good shape. But unfortunately, doing these assignments requires that you actually understand, not just be able to compile the source code that we gave you. There's 40,000 non-commenting lines of code in the OS 161 sources, and by assignment three, you will have added several thousand more to that set. I also want to point out, though, that as a pedagogical code base, OS 161 is extremely well-commented. There's 25,000 comments, which is pretty impressive. That's sort of a ratio of one comment for every two lines. So reading this code will help you, and there's plenty of commentary there that we'll try to help you still. So the trick when you approach a code base like this is to divide it into three categories. There's code that we've given you that you do not need to understand at all. And if you find yourself reading that code in the process of trying to debug something, you've probably gone down a bad path. There is code that you need to have intimate knowledge of that you really need to understand very, very well. And then there's code that's kind of in a gray area, where you need to know something about it. You don't need to know it deeply, but you need to know it's there and sort of what it does and how to understand it if things go wrong. So and putting things into that category is sort of the critical task here. So let's get back into our virtual box here, so I'm going to see if this guy is still running. Looks like it is. Okay, great. So here's the source directory that we cloned before. One thing I want to point out here is that the path, or sorry, the prompt here, that default prompt in your bigger virtual machine has some nice features to it. You may want to change it, but what's showing me right now here is the branch that I'm on. So there's only one branch in this repository. It had more than one branch, as it would show you which one you were on. You may or may not want to change this by modifying your bash RC. Okay, so let's look sort of what's in the top directory here, right? I have a build directory that is used during why you build the user tools. There's nothing really that that's particularly interesting in there. Most of the directories here are really concerned with building user land tools, so you have man pages in here. This can be something that you might want to share. So the fact that this is shared here with my host is pretty useful because I can actually open this up and check it out. So here's my reference manual for OS 161, and this will tell you sort of a lot about the base system, right? So here's some information about the Hall command, for example. Okay, so that's there. Pretty useful. But most of the stuff here is user code. So you have the binaries in, sorry, let me go back up here. So I've got user land. This is where all the user binary code is. So the user program, so here's, we talked about true in class, and here's been true, and just as promised, all bin does is exit with success, whereas if I go up here to bin false, all it does is exit with failure. So okay, so here's our user code. Like I said, I'm going to make this quick. So let's get to the good stuff. Let's get into the kernel directory. So this is where the interesting things are, and it's important to kind of understand how things are organized. So in the Arc directory, you have architecture specific code. So there are two subcomponents of the architecture here. There's the stuff that's specific to the MIPS instruction set and sort of system architecture that you're OS 1621 source is designed for, and then there's actually a code that's specific to the system 161 simulator. So David has put things into these two subdirectories. And there's code in here that you may or may not want to look at. There's things in here that you will definitely need to understand. And there's other code that you probably won't need to understand. So let's look in here. This is kind of interesting. As the assignment points out, the sources for OS 1621 are a master of C, which includes both .c and .h header files. And then assembly codes. So here's a piece of assembly code. This is start.s. And this is actually what this is the kernel entry point. So this is the first code that started by the bootloader, the system 161 bootloader when your kernel boots up. So that's pretty neat. You'll notice here, as I promised, that the OS 1621 sources are extremely well commented and the assembly code, while it may be a little bit scary, is even better commented than most of it. So you can see that there's this long comment here. And if you read some of this, actually, you can get some idea of what the assembly language instructions here are doing. In general, though, you don't really need to understand the assembly code that you can give them for this class. All right, so let's go and let's look at them. So obviously, you know that the boot stuff is very specific to the system 161 simulator and how it boots. But let's look in our archmips directory. Now here's some interesting things. Here's ram.c. This is actually called during boot to set up to determine how much physical memory is available. Look at that. Here's a comment that told me exactly what it says, so that was nice. So anyway, this has some functions that are used during assignment 3, but really what we're here to do is just go to sort of look around to get a sense for the layout. OK, we will come back into archmips, but let's go back to the base kernel directory. So you've already used the compile and configuration directories when you built your currently have some idea what's in there. Dev. So let's go into dev and look around. This stuff you probably will not need to change. This is code for essentially kind of device drivers for some of the suited devices that are provided for the system 161 simulator. In the file system directory, we have file system related code. Because we don't do the file system assignment right now, for the apps class.org assignments, this is not stuff that you will need to look at. All right. GDB scripts, I actually have no idea what's in there, so I'm going to leave that alone. OK, the include directory. So this directory has includes that are used by the kernel. And then there's this current subdirectory. So it turns out in order to interact with user programs, there's certain information that the kernel needs to export to user space. There are header files that are shared between the kernel and user programs. And this is where those live. So for example, in order for the system call interface to work, and this is something we'll talk about more in class, there needs to be an agreement between the kernel and between user programs about what the system call numbers are. So this file, which is shared with user space, defines the system call numbers. So if I pass zero to syscall, what I want to do is a fork. OK, so let's go back to Kern and keep looking around here. OK, so now I've got a live directory. This has some sort of like common routines that the kernel uses, things like keyprintf, for example. So here's a definition of keyprintf, which is the main printf function that's used by the kernel. And actually, one thing you'll notice here is that keyprintf will try to acquire a lock in order to protect its output, and this is something that doesn't work early in boot. OK, so onward, we've looked a little bit and lived. Main has some interesting things that you probably want to look at, including the code that runs the menu and main.c. So main.c is kind of the main entry point for the kernel. You can think of it as main for a typical program, and actually it's not main, but there is something called kmain, right? What does kmain do? It calls boot, runs the menu, which basically loops accepting arguments, and then shuts down. So this should not execute because the menu should quit after you hit Q. All right. What is in proc? I don't know why. I thought there was a proc directory. Oh, sorry. So here we are. Let's go into proc. And this is just very, very limited process support that's been introduced in for the new version of OS 161, and this is something you'll come back to in assignment 2. OK. So sync.probs has code that you're going to use in assignment 1, and this is something that we'll go over more when we talk about that assignment. The VM directory, there's not much in here yet. It does have the kmain alloc code for the kernel allocator. The VFS is the virtual file system implementation, so that has sort of common, provides the common abstraction that are used by the file system specific implementations. One directory you might want to look at is test. So the test kernel directory has a bunch of different things in it, and these are tests that we're going to be using to test your kernel and to make sure that things work. So for example, the sync test file has a bunch of tests. These define the tests that are run as SY1, SY2, SY3, and SY4 from the kernel menu. And you are encouraged to understand this code. This gives you some starting points for some of the things you want to do in assignment 1, but one important caveat is that when we test your kernel, you are not allowed to modify anything in this directory. So you can modify it when you do things if you want to add some tests or see how additional things work, but when we test your kernel, we will overwrite the contents of the test sub directory. That's in order to make sure that when we test your kernel, you're actually running the tests that we want you to run and not something that just always succeeds. Okay, so in the thread directory, this has some basic routines related to threads on OS 161. This is thread.c, in particular, is a good thing to look through and to understand how some of this works. Okay, and that's pretty much it. So that's kind of an introduction. We didn't look in syscall, we can. This has some, this is sort of a starting point of a directory where you will put files that will implement the system calls that you'll build as part of assignment 2. All right, so let's go back to the assignment here and that we've done our extremely rapid overview. A lot of this is sort of documented right here in the assignment text, but I want to just look at one of these and talk a little bit about how you can answer questions like this in the context of a system like OS 161. So I know a lot about this system, so it's difficult for me to reproduce the feeling of being you and starting from scratch. But let me just sort of talk about what I would do, right? So let's talk about, let's talk about question number 7. So what is a zombie thread? That's a pretty high level question and what I've given you is a bunch of C codes. So how are you going to address this? Well, here's what I would do. I would go into the kernel directory because that's kind of, you know, where I figured out where the interesting stuff is. And I would do this. I would grep for, make that grep insensitive, zombie. And check that out, right? So what have I found here? I've got some stuff in GDB scrolls, which is safe to ignore. And then look at this. I've got some things in thread.c. Okay, so that's interesting. And it turns out that there's a comment right here that seems useful. So let's take a look at thread.c. So same thing here. I'm going to look around for zombie. And here is exactly what a zombie thread is, right? So cleanup zombie. Zombie server threads that have exited. But still need to have thread destroy called on them. So that is the OS 1621 definition of zombie. And I've answered this question, right? Now, I cheated a little bit here, right? Because this question is probably the one that has the best keyword embedded in it. But a lot of the questions that we're asking are things that, you know, with a little bit of grepping around, you'll be able to figure out. And so that's my suggestion for how to do that. Things like C tags, I think it's called exuberant C tags, are also potentially extremely useful. You can certainly install those in your virtual machine and use those as part of your VIM development environment or whatever you use. And this is a nice way to navigate a code base like OS 1621 if you choose to use VIM, which is certainly supported. All right, so that's all for this. The next screencast will look a little bit at how to use Git.