 All right. So yes, what you'll have to do is first actually set up your private Git repositories. And then after that, with your private Git repository, whatever changes you make on your local repos that you fetch from the staff's repo, whatever thing you need to configure it with your private repo and push it to that. A simple Git clone will not work just because the way in which it is set up is that first it will clone everything and you will not face any problems. But when you try to push using just a Git clone interface, what's going to happen is it's just going to try pushing it to the staff's implementation of your OS 161 and you guys don't have the permission. So a simple Git clone will not work. Just to show you an example, what I'll do here is the same stuff. So I'll go to like oops class, so the assignments and then your assignment 0 is the link for the Git repository. I paste this thing here and it clones into OS 161. Now I go here and, for example, I do some changes in something else. I just change maybe one small symbol here and then Git, add, whatever, Git, commit, and I'll give something and then Git, push, origin, master. It lasts me things like these which maybe I'll just give my name and I don't know the password because I'm not a registered user and it will say like authentication failed. So what I did just now is a simple Git clone that didn't work. What you'll actually have to do is, so I remove OS 161 and I create a new directory. I'll call it new OS 161, MKDIR, new OS 161 and I'll go here. I'll initialize Git here and I'll add a remote and I'll call this thing origin. And what is this? This is where things come from, right? So I paste it here. Now I'll add another remote, like how to? Like add an SSH key. Add SSH key. Or create an SSH key. OK, cool. That's a good point. So how to add an SSH key? I'll first come back. OK, fine, cool, awesome. So just for reference sake, what I'll do is I'll just sign into my account and after I sign into my GitLab instance, I create a new project. So I'll go to, this is my dashboard, projects. I'll create a new project here. This is be, let it be my private, OK, it has to be a private project and I'll call it like new OS 161. I create a project. Now it's giving me instructions what to do here, right? So create a new repository or existing folder or Git repository. So what I'll have to do is follow the second instruction here. That is, I need to Git init first and then Git remote add things and then push it to this. So the way in which I have set up things is I have my local instance here. That is my local directory, which is new OS 161. I pull from the origin, as you can see the name here, like origin, and I'll add one more thing. Git remote add, and I'll call this thing as my OS 161. And what is the path for this? This is the path, right? I copy this, I paste it here, I hit Enter. Now I have two remotes which are associated with my directory that I'm working with. So all I need to do is Git pull. So Git pull origin master. Let's see if this thing succeeds. It did. So I have all my configuration files here. And if I'll have to make any changes, so I'll go to config and make some changes here. I'll just remove this stuff. Some random changes. Git add, and after I Git add, I Git commit and give it a random message, something. And then Git push my OS 161, and I'll give it a name master. Let's say yes, pre-notary, please make sure you have the contact access right. The authentication of this one cannot be done. The reason being that is because, as Bridges pointed out, I don't have the proper SSH keys, I guess. Git push, upstream, master, permission denied, public key. As you can see, you guys would get this error. So all I need to do is I'll have to generate a new SSH key so that it can be uploaded to my Git lab instance. I've already generated that, but just in case if you guys are interested to generate that, just use this command SSH keygen. You guys hit Enter because it's already generated. What I'll do is I'll run that command, but I'll just make a backup copy of my SSH keys. So SSH, I'll move my dot SSH to backup SSH. LS minus LA dot SSH, there is nothing here. Cool. So I'll run that command again. So enter the file in which you want to save the keys. It's giving me a default option, like dot SSH, ID, RSA. Fine. And then I don't want any passphrase. No passphrases again. This is just some random art which is chosen based upon some random clock generations. And yeah, your SSH keys would be there present in your dot SSH directory. So you can find two keys. ID, RSA is your private key. You're not supposed to share that with anybody. And your ID, RSA dot pub is your public key. All you'll have to do is go to your Git lab page, and there go to Settings. And in Settings, or not the project settings, it's just your private settings. So where is it? In Git lab, profile settings, yes. So you can find an option here called SSH keys. I'll add my SSH keys here. So I'll add this thing. Whatever content has been generated here, copy that, paste it here. Cool. Awesome. But why is there a line? I don't want the line. ID, underscore, RSA, public, all right. Anyway, and I'll call this thing as recitation. I add my keys. And it's all fine here. So what I do is, yeah, all my SSH is configured properly, right? So I'll jump back to my new OS 161 directory again. And then I made changes here, right? So to see the stuff that I made, so my Git status is I'm on branch master and nothing to commit. So it basically means that I have already done all my commits properly. So as you can see here, my commit is visible here. Now I'll just have to push to upstream. So Git, push, upstream. And what are the names? Yes, my OS 161. And I'll push it to the master thing. I just type in yes. And it permanently adds its stuffs. And hoping things work. And yes, it did work. So maybe that gave you just about how to go about setting up your SSH keys. The command that you just have to use is SSH key gen. That's it. And it will lead you through the rest of the procedures. So once when you get things done and set up like this, you're all set to go about developing things. Any questions? Are you guys clear? Or just whatever questions you guys have to ask. This should be done by Friday. I mean, your entire assignment 0 should be completed by Friday. Yes. So if you guys don't have any questions, I'll move on to the next portion of GDB. So just a quick question. How are you guys actually setting things up? Are you guys setting things up on your native machine itself using PPA or Vagrant? Vagrant? OK, cool. Because sometimes you guys might have issues when you're setting things up on your native machines. So it's good to have a Vagrant installation. Well, possibly nothing wrong will happen. But sometimes in case just your path variables or something are configured differently, then maybe if for some reason you have some old OS 161 version lurking somewhere in your system, then it might get confused with those path variables. And a wrong SIS 161 simulator might be called. Many, many such things like this could happen. So because of that, if you have just virtual machine instances that does only one thing really well, then that's what is the most optimum way of going about doing things. Yep. Say that again. So why is 15.04 not recommended? Yes? It supports the 14th. Yeah, I mean are you able to configure everything properly? Is everything working all right as of now? Then you can just continue doing that stuff as long as you don't encounter any errors. But in case you encounter any errors, I mean it will take a very long time to us to debug as to why exactly things aren't working. Because when we were setting up this Vagrant, we had some issues with the Tmux version. So even the versions of some particular softwares might have issues while compiling stuffs. So we have tested our stuffs well on Ubuntu 14.04, the LTS edition. But with the other things, you guys could go about experiment with it. But just in case if it doesn't work, maybe we can fix it, maybe we cannot fix it. We don't know. All right, anyway, back to our stuffs, what we were doing. All right, so my next objective right now is to show you how GDB works. So what I did was I set up a Vagrant installation. Where did I do that? This should be in the desktop. Oh no, it's in OS 161. So here I have a Vagrant installation. And I have a Vagrant file here. All I need to do is just call Vagrant SSH. That's it. I'm logged into my system here. OK, to go about experimenting with GDB, you'll have to have a minimum of two terminals open. So I'll open up another terminal. So I'll log into my machine here. I'll change the font. Actually, like gd.csintot. I'll change the color, change settings, appearance. OK, cool. So here I'll go to OS 161. And here I'll go to my Vagrant file. Vagrant SSH. So I have two terminal set up here. You guys know how to compile and then create your root directory and to create your kernel images. I wouldn't go through that again because all that is pretty straightforward in the assignment 0 description. So once when you generate your root directory, once when you generate everything fine, you'll get all these files populated under the root directory. And the most important stuff that you end up working with always is your linked file called kernel. So whatever simulations you do here, I'll just start my sys161 system simulator here on the kernel, logged by another process. It's because I left the kernel running on my host system in my lab. So what I'll do is exit this. Vagrant help. I'm trying to describe those things that I created. Reload, restart Vagrant machine. Maybe I'll reload stuff. Vagrant reload. So once when the machine boots, we will try SSH'ing into it again. Awesome. So Vagrant SSH and Vagrant SSH. So I have two terminals here. And I'll go to my root directory. And in my root directory, hope it works, sys161 kernel. Cool. My kernel is booted right now. So once when your kernel is booted and everything works fine, this is the kind of output that you get. So I'm in my system simulator of my kernel. And all these are the commands that you can test things out with. And you can just browse around this stuff. And once when you get your assignment 0, everything properly set up, this is what you'll see. So I'll show you just quickly how to go about using GDB. So when you look at the manual pages for sys161, you can see that there's a particular option, which is this thing, like minus w. And it'll wait for a debugger connection. So you can attach a debugger to your kernel. So the OS161 documentation says properly that in order for you to debug the kernel, your sys161 needs to be running in the background. So that's what I'm doing here. I'm running my sys161. And I'm running the kernel on top of the sys161 and making the sys161 simulator wait for a debugger. So it's waiting for a debugger. I switch to my second window. And I should always make sure that I'm in the same directory where my kernel file is. And here I just start OS161, GDB. And yes, and here, what's the command that was stated online? Some target, right? Target remote unix forward slash socket. I don't remember it properly. Could somebody just find it out? Target, right? OK, yeah, this is it. Dot sockets slash GDB. So it's dot sockets slash GDB. Cool, awesome. So I go back to this window. And before it was saying that it was waiting for a debugger connection, I would say is that the debugger is actually connected. So I'll just, you know, there's a command in GDB called continue. So what it will do is it will continue from your debugger. It will make the OS161 to continue. So, well, it's continuing. It's well and fine. Maybe here I'll generate a new panic. And I get the output messages from my debugger here that the program has received a signal trap. I can do many other interesting things from my GDB as well. For example, I can see back trace. I can see how the stacks of the frames are actually organized and how to go about debugging things in a more effective manner. What I'll do right now is just temporarily set a break point. I'll just set a break at panic if I encounter panic or wait. I'll just restart this again. And I'll target remote. Yes. And break at exception. No symbol table is loaded. I'll just put yes. I'll just continue. Now it continued. And well, for some reason that stuff isn't working properly. I don't know for what reason. I'll show you certain other commands as well you can do from GDB. This is the target remote. I showed you continue, right? You can step into things. So continue and step are two different things. Continue keeps on continuing until the next big point. And just steps through different things like once when a break point is actually encountered. So I don't know why is this thing not setting up break points? Oh, OK. I got you. Who is one GDB kernel, right? So I quit here. Yes, who is one? Yeah, this is what I didn't do. So target, remote, unix, forwards, sockets. What was this stuff? GDB. GDB. And I come here. Cool. Awesome. So I can set break points like this. I'll set a break point at, OK. Now I'm getting autosuggest options when I hit the tap button. I'll set a break point at panic. And I'll just continue until the panic is encountered. So I'll just hit question mark and different things here. And I'll generate a panic from my kernel. And you see, I got the break point. Now I can backtrace things and look at stuff. Anyway, since the time is already up, I would stop my explanation here. And just go about experimenting with GDB features. And Git and GDB are very important tools to play around with in your assignments. All right, thank you.