2006-12-16
The Layman's Guide to the Linux Kernel
Before we begin we need to get a bit of background history both on what an OS is and where Linux comes from. We will start with the beginnings of Linux. Keep in mind that this session is intended for the new user with little or no technical experience, and will not get hung up on terminology. We will be spending a lot of time dealing with modules, I thought long and hard about whether or not this was important and decided that if there was one thing users should learn, its how to deal with modules. Most users wont compile there own kernel, but many with have their own set of modules to deal with. So that will be a large focus.
Linux
Linux IS a true Unix, it supports the Unix standards, it will run Unix programs. From the point of view of the user, we see it as a Unix. However there is a key difference, Unix is closed (excluding BSD's), Linux is open source, and equally as important, free to the user. Linux started as a small Hobbyist OS, written by Linux Torvalds, and moved up from there. As it grew in complexity so did the OS which ran on top of it, which too began to be called Linux (or GNU/Linux). This has become a small point of confusion however, Linux is the name of the kernel, but also the name of the OS (from the layman's point of view). The difference may not be clear now, but it will be later. To contrast this, OS X has a kernel named XNU (X is Not Unix) and Windows has (had) a kernel named NT. As you may guess, this has lead to confusion over what Linux actually is. Let us be clear, Linux is the kernel on which Linux, the operating system, runs on top of. Confusing? Probably, so we need to discuss what an Operating System actually is.
Operating Systems
Operating Systems are the most basic set of programs on your computer that make the work you do possible, this DOES include the kernel. Make note, an Operating System has a Kernel, but a Kernel is not an Operating System. Sometimes you interact with the OS directly, sometimes through the applications you use. So let's lay out the hierarchy right now, we have to do it eventually and it always seems too early. There are layers to a computer operating system, four of them in Unix to be precise. Layer one, the very top layer, we will call Users. Layer two we will call Shells, layer three will be Linux (the Kernel), and layer four will be the hardware itself. These layers interact with one another in order, users talk to shells, shells talk to the kernel, the kernel talks to hardware. From this rather simplistic view it is easy to guess where the rest of the "OS" is if its not the kernel, and clearly its not the user, it must be the "shells". And thats pretty much right, before we had a GUI (graphical user interface) your OS was the shell and all the basic commands you could run from it. Even today for the most part GUI applications are not really part of the OS but things that run on top of it (excluding the case of Windows). I am going to take a quick break now to answer any questions with regards to the basic difference of the Kernel and the OS. I hope you can see that basically everything you deal with on your computer is the higher level layers of the OS and the kernel is more of an invisible layer of the OS (so far).
Meeting Your Kernel
Lets discuss a couple of the features of the Linux that makes it special. Linux is a multitasking operating system, which also means its kernel has to handle multitasking, after all, it is part of the operating system. What does this mean? Well it means that the kernel is taking care of "interrupting" applications so that another one can work. Keep in mind that your computer can only really do one things at once, so when it works on one thing it puts other things on hold. It is the kernel that decides which thing needs to work and when, and it is very smart about it. Your kernel will take note when one application is waiting on data, for example if your music player is waiting on that mp3 file from your hard drive, it can't start to decode it until the file gets there. So the kernel will put that process on hold until the data gets there, giving other processes a chance to use the hardware. This takes place very very very fast however, in the short time we have been discussing this your kernel has switched between different tasks thousands of times, making sure they all have the processing time from the hardware that they need. This very basic functionality was one of the most important features in early kernels/operating systems and today remains one of the core technologies of computers. Without this ability, running more than one application at a time would become impossible. The kernel like we mentioned, deals with all hardware interaction, so when you save a file, your application makes a request that gets passed along to the kernel. The kernel will make the decision on whether or not to let you, and even when to write it out. In general Linux will delay actually writing the data to the hard drive as long as reasonably possible so that if the data is called up again, as is quite often the case, it already has it loaded in memory (note that one of the slowest devices in your system is the hard drive).
Having so many programs running at once can cause its own issues for the computer. Each program will need its own set of memory from the system. So it calls out to the kernel says "hey, I need 10MB of memory" and the kernel says back "ok, here you go, your memory is at address 400-2000". However often times poorly writing applications might try to write to memory they are not assigned, and if they were allowed to this could result in a whole range of badness all the way up to a full fledged system crash. The operating system will prevent this of course, this is called Memory Protection.
One of the most fun bits of Linux is just how portable it is. Everyone jokes that they have Linux running on their wristwatch and so on, but in the end it really can be run on just about anything. It runs on PDA's, Routers, Macs, PC's, Sun systems, I'm sure it would run on R2D2 if we could get him to stop saving the Universe for a minute. In fact Linux runs on 20+ different processor architectures, it will even run on your iPod. However this was not always so, and Linux has had to go through a lot of work and different versions to get there. We are currently in version 2.6.17 in Edgy Eft. These numbers are not just random, so lets look at them for a bit. The first number defines the kernel version, and is changed only when VERY major changes in the kernel occur. In fact this has only changed twice, one from 0 to 1, and again for 1 to 2. The second number designates then major revision of the kernel version, and the third number is minor revisions (driver changes and so on). You will sometimes see a forth number tacked on, these designate a bugfix or security release that does not quite justify a new minor revision.
There is a bit of confusion going around right now about even and odd numbers. Even numbers are often said to be stable releases, odd numbers unstable releases when talking about the second number. So 2.6 is said stable and 2.7 unstable. This actually used to be the case, which is where the confusion comes from. Prior to the 2.6 release, even numbers did mean stable and odd meant development. So 2.4 was a stable release but 2.3 was a developer release. Please note that this is no longer the case, odd and even have no more significance.
In fact, all of this is not so far out of your grasp, we can actually look and see what our kernel has been up to. If you open up your terminal and type the command "dmesg" you can see some information about what your kernel has been up to. A lot of times you will see info about hardware drivers being loaded, network interface errors, hits on firewall rules sometimes pop up in there. This is the most basic way to interact with your kernel, by looking at what it has to say. This has a lot of usage and some of you may have even been asked to use this when troubleshooting problems in #ubuntu.
Your Kernel is Voltron
Some of this may be confusing at first, but we will be doing a hands on excersize shortly. There is one other key feature to talk about however, that being kernel modules. Kernel modules are, unsurprisingly, modular additions to the kernel to add functionality. The most common kind of kernel module you will deal with is a device driver. If you are running a nvidia video card and you wish to have OpenGL working, you need to load the nvidia kernel module. Even things like file system support have been put into kernel modules today, there are tons of them. To see all the kernel modules you have loaded right now, type "lsmod" in a terminal. To see how many of them there actually are, pipe that to wc -l, so "lsmod | wc -l". Most of you will see things like "soundcore" which is the core of sound production, or "floppy" which provideds floppy disk support. However some of them like.... say agpgart are not so obvious. However if you look to the right a bit you can see two sets of numbers, those give the size of the module and how many times they are in usage (you can use a module multiple times). To the right of that it lists even more modules, you can think of these modules as depending on the module you are looking at, because more or less they do. So it becomes pretty clear now, agpgart is loaded because your video card needs it (for the AGP bus).
Even still some modules don't have anything listed as things that depend on them, but we can still get more info. Running the command "modinfo font" gives us information about the module named "font". This will give us information about the license, author, and a basic description of the module. In this case James Simmons is the author, he licensed it GPL, and the module provides us with Console Fonts. To simply get the description of the module, you can do "modinfo -d font", however if the module has no discription (as is often true or closed source modules), this will return nothing. One thing to note about modules is that they do not HAVE to be modules. When you compile your kernel (which we will not be covering), or it was compiled for you, modules can be compiled into the kernel directly so they cannot be removed. This makes the kernel custom to the machine you are on, but makes it essentially useless for things like Ubuntu where we have a large number of people using the same kernel.
Insert/Removing Your Own
There is more to do with kernel modules however, you can insert your own kernel module with "sudo modprobe [kernel module]" and the module will be inserted until it is either removed or the machine is rebooted. You can even remove them with "sudo modprobe -r [kernel module]". So let's try it out, I encourage everyone to give this a run. We are going to load in a dummy module, confirm that it loaded, then unload it. First we load the module with "sudo modprobe dummy". Generally when we enter this command nothing will happen, just a new line and no output, that means no errors as far as finding the module. Now if this were a real module we could run the command "dmesg" which we talked about earlier to see info about what the module has done thus far. This is extremely useful in the case where you module is loading but it does not seem to be working properly. Let's confirm that the module has indeed loaded using the "lsmod" command. Run "lsmod | grep ^dummy", we are piping it to grep to do a search, and searching for a line that starts with (carrot means start with) dummy. You should see the output. Now run the command "sudo modprobe -r dummy" and then search for dummy in lsmod again. It is no longer there. That is all there is to loading an unloading modules, however doing things manually sucks, there are better ways.
Loading/Stopping Modules at Boot
Often users will find they have to load modules to make certain parts of their hardware work. For example a lot of TV Tuner card users must load the ivtv module when they boot. This, by the way, does not come with Ubuntu so they also have to compile it but thats a whole other class. To load a module on boot you simply add the name of the module to the end of /etc/modules. So ivtv users would add ivtv on a new line to the end of that file. If you wished to prevent a module from loading which is not uncommon for ndiswrapper users, you would add a line that looked like "blacklist [module]" to /etc/modprobe.d/blacklist. This would prevent the file from being loaded at boot and allow you to add ndiswrapper to /etc/modules safely. Learning to deal with modules in Linux is not needed, but it sure does help.
This closes out todays session on the kernel, if you have any questions feel free to ask at this time.
Raw Log
15:02 < DBO > let me first lay out the ground rules 15:02 < DBO > there are two breaks for questions, one in the middle 15:02 < DBO > and one half way through 15:02 < DBO > feel free to /msg me questions at any time though and I will get to them during the question sessions 15:03 < DBO > this topic is intended for new users mostly 15:03 < DBO > and for users who hear the word kernel and think popcorn =) 15:03 < DBO > so lets begin 15:03 < DBO > Before we begin we need to get a bit of background history both on what an OS is and where Linux comes from. 15:04 < DBO > We will start with the beginnings of Linux. Keep in mind that this session is intended for the new user with little or no technical experience, and will not get hung up on terminology. 15:04 < DBO > We will be spending a lot of time dealing with modules, I thought long and hard about whether or not this was important and decided that if there was one thing users should learn, its how to deal with modules. 15:04 < DBO > Most users wont compile there own kernel, but many with have their own set of modules to deal with. So that will be a large focus. 15:04 < DBO > However before we can really dive into all of that 15:05 < DBO > we need to get a general idea of what Linux actually is 15:05 < DBO > many of you may know already that linux is a unix like operating system, and from the users point of view it is perfectly ok (ideology aside) to think of Linux as a type of Unix 15:05 < DBO > However there are a couple key differences 15:06 < DBO > namely, Unix is closed source (excluding the BSD's) where as Linux is open source, and equally as important, Linux is free to the user. 15:06 < DBO > Linux started as a small Hobbyist OS, written by Linus Torvalds, and moved on from there. 15:07 < DBO > As it grew in complexity, so did the OS that ran on top of it, which too began to be called Linux (or GNU/Linux) 15:07 < DBO > This has become a small point of confusion however 15:07 < DBO > Linux is the name of the kernel, and it is also the name of the OS which incorporates the kernel 15:08 < DBO > To contrast this, OS X (apples OS) has a kernel named XNU, and Windows up to Vista, had a kernel named NT 15:08 < DBO > AS you may guess, this has lead to a lot of confusion about what Linux actually is 15:08 < DBO > So for the sake of this class, let use be very very clear, Linux is the kernel on which GNU/Linux, the operating system, runs on top of. 15:09 < DBO > Confusing? Probably, so we need to also briefly cover what an Operating System is 15:09 < DBO > Operating Systems are the most basic set of programs on your computer that make the work you do possible, this DOES include the kernel. 15:09 < DBO > Make note, an Operating System has a Kernel, but a Kernel is not an Operating System. 15:10 < DBO > Sometimes you interact with the OS directly, sometimes through the applications you use. 15:10 < DBO > So let's lay out the hierarchy right now, we have to do it eventually and it always seems too early. 15:10 < DBO > There are layers to a computer operating system, four of them in Unix to be precise. 15:10 < DBO > Layer one, the very top layer, we will call Users. Layer two we will call Shells, layer three will be Linux (the Kernel), and layer four will be the hardware itself. 15:10 < DBO > so it looks like: 15:10 < DBO > Users 15:10 < DBO > Shells 15:11 < DBO > Kernel 15:11 < DBO > Hardware 15:11 < DBO@> simple enough? 15:11 < DBO@> oh thank you =) 15:11 < DBO@> its hard to get good help =P 15:11 < DBO@> anyhow 15:11 < DBO@> These layers interact only with the layer above or below them with a couple exceptions we wont be covering 15:12 < DBO@> So as a user to get something done, you interact with shells, shells interact with the kernel, the kernel interacts with the hardware, gets the result, and passes the info back up the chain of command 15:12 < DBO@> From this rather simplistic view it is easy to guess where the rest of the "OS" is if its not the kernel, and clearly its not the user, it must be the "shells". 15:12 < DBO@> And thats pretty much right, before we had a GUI (graphical user interface) your OS was the shell and all the basic commands you could run from it. 15:13 < DBO@> Even today for the most part GUI applications are not really part of the OS but things that run on top of it (excluding the case of Windows). 15:13 < DBO@> Do however keep in mind that what is and is not part of your OS is often a fuzzy line 15:13 < DBO@> This is the basic set of knowledge we need to continue on with our kernel 15:14 < DBO@> at this time we are going to take a short 5 minute break for questions 15:14 < DBO@> I want to make sure everyone is fairly clear on what is going on ehre 15:14 < DBO@> you may ask questions directly in the room =) 15:14 < Ma1kel > Are you single?? 15:14 < DBO@> no 15:15 < Wooksta > whats the expected duration of this class (approx)? 15:15 < DBO@> I can adjust for your preference =) 15:15 < Ma1kel > :)) 15:15 < Wooksta > well i aint got much to do for the rest of the night so go as low as u want :P 15:15 < DBO@> everyone is clear on these basic concepts then? 15:16 < LjL > DBO: is my thinking correct that even the concept of a "kernel" can really only apply when you're talking about an OS that runs with 1) virtualized memory and 2) kernel protection (i.e. applications can't go into kernel mode)? 15:16 < LjL > at least, the possibility of clearly separating "kernel" and "the rest" without putting another fuzzy line on there 15:16 < DBO@> LjL, in the sense we will be discussing it yes 15:17 < DBO@> LjL, it gets fuzzy when you talk about multi-tasking operating systems that dont offer virtualized memory and kernel protection in any sense 15:17 < DBO@> but those are no longer around so we wont worry about them 15:17 < LjL > DBO: yes, that was the kind of thing i had in mind, and yes, i realize it hardly applies to today's systems anymore 15:17 < DBO@> its a very good point though 15:18 < DBO@> as computers grow in complexity 15:18 < DBO@> it becomes harder and harder to figure out what classification any one piece of code belongs to 15:18 < DBO@> any other questions? =) 15:19 < DBO@> ok let's move on 15:19 < DBO@> Im going to leave that off 15:19 < DBO@> just ask question whenever since there is not many people here =) 15:19 < DBO@> We can move on to discussing a couple features that make the Linux kernel special 15:20 < DBO@> these features are present in other kernels of course, but they are some of the most basic features of the Linux kernel that make everything you see and do on Linux possible 15:20 < DBO@> Linux is a multitasking operating system, which also means its kernel has to handle multitasking, after all, it is part of the operating system. 15:21 < DBO@> What does this mean? Well it means that the kernel is taking care of "interrupting" applications so that another one can work. 15:21 < DBO@> Keep in mind that your computer can only really do one things at once, so when it works on one thing it puts other things on hold 15:21 < DBO@> It is the kernel that decides which thing needs to work and when, and it is very smart about it 15:21 < DBO@> Your kernel will take note when one application is waiting on data, for example if your music player is waiting on that mp3 file from your hard drive, it can't start to decode it until the file gets there. 15:21 < DBO@> So the kernel will put that process on hold until the data gets there, giving other processes a chance to use the hardware. 15:22 < DBO@> This takes place very very very fast however, in the short time we have been discussing this your kernel has switched between different tasks thousands of times, making sure they all have the processing time from the hardware that they need. 15:22 < DBO@> In fact, this is where the concept of processor time comes from, the more a process has to access the hardware, the more processor time it uses. 15:22 < DBO@> This very basic functionality was one of the most important features in early kernels/operating systems and today remains one of the core technologies of computers. 15:23 < DBO@> Without this ability running more than one application at a time would become impossible 15:23 < DBO@> The kernel like we mentioned, deals with all hardware interaction, so when you save a file, your application makes a request that gets passed along to the kernel. 15:23 < DBO@> The kernel will make the decision on whether or not to let you, and even when to write it out. 15:24 < DBO@> In general Linux will delay actually writing the data to the hard drive as long as reasonably possible so that if the data is called up again, as is quite often the case, it already has it loaded in memory (note that one of the slowest devices in your system is the hard drive). 15:24 < DBO@> However this is not without its own problems 15:24 < DBO@> Having so many programs running at once can cause its own issues for the computer. 15:24 < DBO@> Each program will need its own set of memory from the system. 15:24 < DBO@> So it calls out to the kernel says "hey, I need 10MB of memory" and the kernel says back "ok, here you go, your memory is at address 400-2000". 15:25 < DBO@> This is what we call virtualized memory (and no, your kernel does not speak english =P) 15:25 < LjL > DBO: about the hard drive... when a given task is using too much CPU for my likings, i know i can "renice" it, i.e. change the scheduling priority. is there anything like that for I/O activity in Linux? 15:26 < DBO@> for the most part no, I/O will be load balanced fairly equally 15:26 < DBO@> but there is no quick method Im aware of 15:26 < DBO@> So our application has requested from the kernel a chunk of memory, and the kernel has provided it 15:27 < DBO@> normally our application would use this memory and all is well 15:27 < DBO@> However often times poorly writing applications might try to write to memory they are not assigned, and if they were allowed to this could result in a whole range of badness all the way up to a full fledged system crash. 15:27 < DBO@> The operating system will prevent this of course, this is called Memory Protection. 15:27 < DBO@> Older systems this was not the case 15:27 < DBO@> memory protection is one of the biggest improvements in computer stability ever 15:27 < DBO@> One of the most fun bits of Linux is just how portable it is. Everyone jokes that they have Linux running on their wristwatch and so on, but in the end it really can be run on just about anything. 15:28 < DBO@> It runs on PDA's, Routers, Macs, PC's, Sun systems, I'm sure it would run on R2D2 if we could get him to stop saving the Universe for a minute. 15:28 < LjL > ... that provides memory protection hardware ;) 15:28 < DBO@> ah yes 15:28 < DBO@> In fact Linux runs on 20+ different processor architectures, it will even run on your iPod. 15:28 < DBO@> However this was not always so, and Linux has had to go through a lot of work and different versions to get there. We are currently in version 2.6.17 in Edgy Eft. 15:29 < DBO@> These numbers are not just random, so lets look at them for a bit. The first number defines the kernel version, and is changed only when VERY major changes in the kernel occur. 15:29 < DBO@> In fact this has only changed twice, one from 0 to 1, and again for 1 to 2. 15:29 < DBO@> The second number designates then major revision of the kernel version, and the third number is minor revisions (driver changes and so on) 15:29 < DBO@> You will sometimes see a forth number tacked on, these designate a bugfix or security release that does not quite justify a new minor revision. 15:29 < DBO@> There is a bit of confusion going around right now about even and odd numbers. Even numbers are often said to be stable releases, odd numbers unstable releases when talking about the second number. 15:30 < DBO@> So 2.6 is said stable and 2.7 unstable. This actually used to be the case, which is where the confusion comes from. 15:30 < DBO@> Prior to the 2.6 release, even numbers did mean stable and odd meant development. 15:30 < DBO@> So 2.4 was a stable release but 2.3 was a developer release. Please note that this is no longer the case, odd and even have no more significance. 15:30 < DBO@> In fact, all of this mumbo jumbo about what your kernel is doing is not so far out of your grasp, we can actually look and see what our kernel has been up to. 15:31 < DBO@> so the first and most basic command we introduce new users to is the "dmesg" command. 15:31 < DBO@> It is perfectly safe to run this command for yourself, feel free to try it on your own PC. 15:31 < DBO@> dmesg will show you what errors and informational message your kernel has for you =) 15:32 < DBO@> A lot of times you will see info about hardware drivers being loaded, network interface errors, hits on firewall rules sometimes pop up in there. 15:32 < DBO@> This is the most basic way to interact with your kernel, by looking at what it has to say. 15:32 < DBO@> This has a lot of usage and some of you may have even been asked to use this when troubleshooting problems in #ubuntu. 15:32 < DBO@> Of course simply watching is no fun 15:33 < DBO@> So we need to learn to interact with our Linux kernel, and to do that, we need to understand that our Kernel is Voltron 15:33 < DBO@> Some of this may be confusing at first, but we will be doing a hands on excersize shortly. 15:33 < DBO@> There is one other key feature to talk about however, that being kernel modules. Kernel modules are, unsurprisingly, modular additions to the kernel to add functionality. 15:33 < DBO@> The most common kind of kernel module you will deal with is a device driver. 15:33 < DBO@> If you are running a nvidia video card and you wish to have OpenGL working, you need to load the nvidia kernel module. 15:34 < DBO@> Even things like file system support have been put into kernel modules today, there are tons of them 15:34 < DBO@> To see every kernel module you have loaded right now, simply enter "lsmod" into a terminal. 15:34 < DBO@> To see how many of them are loaded, you can pipe that to wc -l via "lsmod | wc -l" 15:34 < DBO@> Most of you will see things like "soundcore" which is the core of sound production, or "floppy" which provideds floppy disk support. 15:35 < DBO@> pretty obvious what those do 15:35 < DBO@> However some of them like.... say agpgart are not so obvious. 15:35 < DBO@> However if you look to the right a bit you can see two sets of numbers, those give the size of the module and how many times they are in usage (you can use a module multiple times). 15:35 < DBO@> To the right of that it lists even more modules, you can think of these modules as depending on the module you are looking at, because more or less they do. 15:35 < DBO@> So it becomes pretty clear now, agpgart is loaded because your video card needs it (for the AGP bus). 15:36 < DBO@> Even still some modules don't have anything listed as things that depend on them, but we can still get more info. Running the command "modinfo font" gives us information about the module named "font". 15:36 < DBO@> This will give us information about the license, author, and a basic description of the module. In this case James Simmons is the author, he licensed it GPL, and the module provides us with Console Fonts 15:36 < DBO@> To simply get the description of the module, you can do "modinfo -d font", however if the module has no discription (as is often true or closed source modules), this will return nothing. 15:36 < DBO@> One thing to note about modules is that they do not HAVE to be modules. When you compile your kernel (which we will not be covering), or it was compiled for you, modules can be compiled into the kernel directly so they cannot be removed. 15:37 < DBO@> This makes the kernel custom to the machine you are on, but makes it essentially useless for things like Ubuntu where we have a large number of people using the same kernel. 15:37 < DBO@> Any questions so far? =) 15:37 < jrib > is there any advantage to compiling modules into the kernel? 15:37 < seb35690 > like performance ? 15:37 < DBO@> yes 15:38 < DBO@> performance will be slightly better 15:38 < ShakaNoobSaint > why exactly? 15:38 < DBO@> when you abstract things out to modules and such there is a slight overhead 15:38 < DBO@> when you compile is one hunk of code it is more streamlined 15:38 < DBO@> thats why distros like gentoo compile all the modules you need for your hardware right into the kernel 15:39 < DBO@> of course this comes at the high price of actually having to compile your own kernel 15:39 < seb35690 > how about ubuntu ? 15:39 < DBO@> which in that sense, Linux is fairly unique as the only OS available to users where this is readily available to you as an option 15:39 < DBO@> Ubuntu does not have you recompile the kernel on your own 15:40 < DBO@> so almost all drivers (excluding some very core ones) are loaded in as modules 15:40 < reverseblade > how about smp and apic are these modules too ? 15:40 < DBO@> APIC is, smp is part of the kernel 15:42 < reverseblade > why did we stop ? 15:42 < DBO@> ok we are going to move on 15:42 < DBO@> (was waiting to see if there are more questions) 15:42 < DBO@> Loading/Stopping Modules at Boot: 15:42 < DBO@> wait 15:42 < DBO@> wrong header =P 15:42 < DBO@> I jumped ahead 15:42 < DBO@> Inserting and Removing your own modules: 15:42 < DBO@> There is more to do with kernel modules however, you can insert your own kernel module with "sudo modprobe [kernel module]" and the module will be inserted until it is either removed or the machine is rebooted. 15:43 < DBO@> You can remove them with "sudo modprobe -r [kernel module]" 15:43 < DBO@> So let's try it out, I encourage everyone to give this a run 15:43 < DBO@> We are going to load in a dummy module, confirm that it loaded, then unload it. 15:43 < reverseblade > what do you mean with own modules ? 15:43 < DBO@> well 15:43 < DBO@> not every module gets loaded at boot 15:43 < seb35690 > So we don't have to compile Kernel with Ubuntu for better performances ? 15:44 < seb35690 > I'm a newbie:) 15:44 < DBO@> seb35690, you could get a small performance boost that way yes 15:44 < DBO@> but its not worth it 15:44 < DBO@> the performance increase would be very very tiny 15:44 < DBO@> and hard to measure 15:44 < reverseblade > you don't mean custom modules but , unloaded modules by "own modules" 15:44 < DBO@> yes 15:44 < DBO@> sorry 15:44 < jrib > seb35690: might be a good learning exercise if you are curious but don't do it if you are trying to make your computer go faster 15:45 < DBO@> you can insert and remove modules that are not otherwise loaded in your kernel 15:45 < seb35690 > ok jrib I understand 15:45 < DBO@> First we load the module with "sudo modprobe dummy" 15:45 < DBO@> that command will load in the module named "dummy" 15:45 < DBO@> it doesnt do anything, but its there for fun things like this 15:45 < DBO@> Generally when we enter this command nothing will happen, just a new line and no output, that means no errors as far as finding the module. 15:46 < DBO@> Now if this were a real module we could run the command "dmesg" which we talked about earlier to see info about what the module has done thus far. 15:46 < DBO@> This is extremely useful in the case where you module is loading but it does not seem to be working properly. 15:46 < DBO@> Let's confirm that the module has indeed loaded using the "lsmod" command. Run "lsmod | grep ^dummy", we are piping it to grep to do a search, and searching for a line that starts with (carrot means start with) dummy. 15:47 < DBO@> You should see output containing the word "Dummy" 15:47 < DBO@> this means that your dummy module loaded fine =) 15:47 < DBO@> Now run the command "sudo modprobe -r dummy" and then search for dummy in lsmod again. It is no longer there. 15:48 < narvik86 > rmmod is for the same? 15:48 < DBO@> That is it, that is all there is to loading and unloading modules. However this is only temporary, as soon as you remove them or reboot the machine they will no longer load until requested by you again 15:48 < DBO@> narvik86, yep 15:48 < DBO@> I tend to use sudo modprobe -r as its seems more consistent if you are going to use modprobe to the put the module in, why not use it to remove it too? 15:49 < DBO@> ok 15:49 < DBO@> Often users will find they have to load modules to make certain parts of their hardware work. 15:50 < DBO@> For example a lot of TV Tuner card users must load the ivtv module when they boot. 15:50 < jrib > description for for rmmod says most users will want to use modprobe 15:50 < DBO@> yep =) 15:50 < DBO@> same for insmod 15:50 < DBO@> IVTV, by the way, does not come with Ubuntu so they also have to compile it but thats a whole other class. 15:50 < DBO@> To load a module on boot you simply add the name of the module to the end of /etc/modules. 15:50 < DBO@> So ivtv users would add ivtv on a new line to the end of that file. 15:51 < DBO@> If you wished to prevent a module from loading which is not uncommon for ndiswrapper users, you would add a line that looked like "blacklist [module]" to /etc/modprobe.d/blacklist 15:51 < DBO@> This would prevent the file from being loaded at boot and allow you to add ndiswrapper to /etc/modules safely. 15:51 < DBO@> These files all both owned by root 15:51 < DBO@> and you will need root access to modify them 15:51 < DBO@> however I encourage you to look at your modules and blacklist files and see whats in them 15:52 < reverseblade > DBO, what is the correlation between modules or drivers ,or are there any ? 15:52 < DBO@> there is a large corelation 15:52 < DBO@> correlation even 15:52 < DBO@> in linux, for the most part, drivers ARE modules 15:52 < DBO@> most every single driver on your system is loaded into your kernel as a module 15:53 < DBO@> your kernel can then use that module (driver) to talk to the hardware 15:53 < jrib > can you only modprobe stuff in /etc/modules then? 15:53 < DBO@> nope 15:53 < DBO@> you can modprobe in anything that you have a module file fore 15:53 < DBO@> stuff in /etc/modules will be loaded in at boot however 15:53 < DBO@> so you generally wont need to modprobe it in yourself =) 15:54 < jrib > what's the reason for a blacklist instead of just removing it from /etc/modules? 15:54 < DBO@> (note modprobe is not really a verb, but what do I care?) 15:54 < Wooksta > do u need to specify the full path to a module you build or do you put it in a special directory? 15:54 < DBO@> jrib, your kernel on boot will try to load modules for hardware it detects 15:54 < jrib > DBO: ah 15:54 < DBO@> Wooksta, when you make install the modules it will put it in the special directory for modules 15:55 < Wooksta > ok thanks, whats that dir location btw? :> 15:55 < DBO@> /lib/modules/KERNELVERSION 15:55 < Wooksta > ok thanks :) 15:56 < DBO@> modules are specific to the kernel they were compiled on 15:56 < DBO@> any other questions? =) 15:56 < DBO@> im pretty well wrapped up 15:57 < seb35690 > an example with an Nvidia graphic card ? 15:57 < DBO@> an example for what? 15:57 < Wooksta > im actaully having trouble getting my nvidia card to work but i was gonna ask about that at the end :P 15:57 < seb35690 > "modules are specific to the kernel they were compiled on" 15:57 < DBO@> if you want you can see your nvidia kernel module by doing "lsmod | grep nvidia" 15:57 < DBO@> seb35690, ah yes, perfect example 15:57 < DBO@> Wooksta, well perhaps its a good learning experience 15:57 < DBO@> what trouble are you having? 15:58 < Wooksta > well i installed nvidia-glx and when i do "sudo nvidia-glx-config enable" i get the following error: "Error: unable to load nvidia kernel driver! Be sure to have installed the nvidia driver for your running kern" 15:58 < DBO@> Wooksta, ok run this command 15:58 < DBO@> modinfo nvidia 15:59 < DBO@> does it say it cant find the file? 15:59 < Wooksta > got a whole load of stuff back u want me to look for something specific? 15:59 < Wooksta > filename: /lib/modules/2.6.17-10-generic/volatile/nvidia.ko <-- seems to be able to find the file 16:00 < DBO@> and it seems you are running the ubuntu version to boot 16:00 < DBO@> run this command "sudo nvidia-xconfig" 16:00 < Wooksta > new xorg.conf written 16:00 < DBO@> now restart X and you should be good ot go 16:01 < Wooksta > ok whats the best way to restart x? 16:01 < seb35690 > CTRL+ALT+F1 16:01 < DBO@> log out of GNOME/KDE 16:01 < DBO@> then ctrl + alt + backspace 16:01 < Wooksta > ok brb, thanks :) 16:01 < seb35690 > yes excuse me 16:02 < seb35690 > :( 16:02 < DBO@> seb35690, perfectly ok =) 16:02 < DBO@> ctrl alt F1 switches to a console 16:02 < DBO@> but doesnt shut down X 16:02 < seb35690 > yes i know it 16:03 < DBO@> that pretty well wraps up todays session 16:04 < DBO@> transcripts will be made available 16:04 < DBO@> and I will post the whole speech I wrote and worked from in paragraph form as well
Classroom/Log/2006-12-16 (last edited 2008-08-06 16:59:41 by localhost)