What is a kernel, and why do i need it

Session Logs

   1 [20:53] <_marx_> JFo, is in the house!
   2 [20:54] <JFo> o/
   3 [21:00] <_marx_> Jeremy Foshee is a part of the Ubuntu Kernel team.  He's the reason why the cam you bought from ebay is working.
   4 [21:01] <_marx_> He figures out what's wrong when you hit a kernel bug and makes sure the right people hear about it to get it fixed.
   5 [21:01] <JFo> hahaha
   6 [21:01] <JFo> :)
   7 [21:01] <_marx_> When he's not working on fixing up the kernel, he's started studying bass guitar.
   8 [21:01] <JFo> only just started :)
   9 [21:01] <_marx_> He also lives in the same state as I; North Carolina
  10 [21:01] <_marx_> er me
  11 [21:02] <JFo> Hi Folks, my name is Jeremy Foshee and I am the Kernel Bug Triager for the Ubuntu Kernel Team.
  12 [21:02] <_marx_> grammar nazi
  13 [21:02] <JFo> basically what that means is, I handle the thousands of bugs that are currently active for the kernel package in Ubuntu
  14 [21:02] <JFo> there are several things I hope to accomplish for you all today.
  15 [21:03] <JFo> 1) give a brief idea what the kernel is and why you need it (as the title of the class suggests :-) )
  16 [21:03] <JFo> 2) explain how the team works and how we are a bit different from the kernel upstream
  17 [21:04] <JFo> and 3) show you how you can participate in the kernel community both as a bug reporter and as a triager or community tester
  18 [21:04] <JFo> now then, let's begin shall we?
  19 [21:04] <JFo> The kernel has been likened to a traffic cop in a computer
  20 [21:05] <JFo> it is the but responsible for communications between software you have installed (like rhythmbox)
  21 [21:05] <JFo> and the hardware (like your CD player)
  22 [21:06] <JFo> in this case, the kernel loads a driver so that it can speak your CD players language as it hands it commands from Rhythmbox
  23 [21:06] <JFo> so drivers become something of a tool the kernel uses to speak to various different hardware
  24 [21:06] <JFo> as you can imagine, there are a number of things that can go wrong due to older kernels and newer drivers
  25 [21:07] <JFo> or old drivers on new kernels
  26 [21:07] <JFo> or even the wrong driver for a particular piece of hardware
  27 [21:08] <JFo> having said that, I want to take a moment and describe a new policy that the kernel team has developed to help us further identify the causes of issues and to get them resolved
  28 [21:08] <JFo> this is the 'no duplicates' policy
  29 [21:08] <JFo> in general terms, we have found that
  30 [21:08] <JFo> there are a great many of our bugs that seem related on the surface
  31 [21:08] <JFo> however, upon resolving a bug for one reporter
  32 [21:09] <JFo> we have found that there were many that were not solved due to slightly different chipsets
  33 [21:09] <JFo> so the Kernel Manager, Pete Graner, made the determination that duplicate bugs could potentially hide similar issues.
  34 [21:10] <JFo> now what this means for you and all of your colleagues using ubuntu, is that any bug you encounter related to the kernel should be filed by you.
  35 [21:10] <JFo> even if you find a bug that looks exactly the same. :)
  36 [21:11] <JFo> I know that this seems contrary to common sense, but I assure you that this will help us immeasurably
  37 [21:11] <JFo> any questions for me so far?
  38 [21:11] <JFo> ok, I'll keep going :)
  39 [21:12] <JFo> as some of you may be aware, there is an upstream for the Ubuntu kernel
  40 [21:12] <JFo> this is the kernel team headed up by Linus Torvalds
  41 [21:12] <JFo> there are other team members such as Ted T'so and Greg Kroah-Hartman, but Linus is the keeper of the master tree
  42 [21:13] <JFo> The interaction between the ubuntu Kernel team and our upstream is such that we do a great deal of what we call 'rebasing' from the stable tree as managed by Greg K-H
  43 [21:14] <JFo> we do this for a number of reasons, several being: To keep the kernel we use as close to the upstream kernel as possible so that we benefit from corrections in the code
  44 [21:14] <JFo> as well as security updates and hardware support
  45 [21:14] <ClassBot> Marceau68 asked: How would someone who is a beginner (uhh... me) know when to file a bug as a kernel bug?
  46 [21:15] <JFo> great question!
  47 [21:15] <JFo> the answer is a bit harder to give
  48 [21:15] <JFo> in some cases you won't know
  49 [21:15] <JFo> generally, if some software you are using fails, you would file it for that and when the maintainers of that software determined it was a kernel issue, they would reassign
  50 [21:16] <JFo> however we are also working to help identify when there is a kernel issue
  51 [21:16] <JFo> you will on occasion see a dialog that tells you there was a serious kernel problem
  52 [21:16] <JFo> in these cases you are given the opportunity to file a bug
  53 [21:17] <JFo> there are quite a lot of bugs that get filed for other packages and then sent to me
  54 [21:17] <JFo> so don't worry too much if you think you are doing something wrong, someone will always be around to help
  55 [21:18] <JFo> the kernel team itself works in a FreeNode channel. The #ubuntu-kernel channel
  56 [21:18] <JFo> so if you think you have  a kernel bug, you can ask in there for verification
  57 [21:18] <JFo> the folks on the team are always glad to help :)
  58 [21:18] <ClassBot> maco asked: when hardware is being stupid, should we file against the linux package and then let someone more knowledgeable in the ways of the kernel (*cough*you*cough*) sort out whether it's really hal's or pulseaudio's or whatever's fault?
  59 [21:19] <JFo> sure, but keep in mind that I am managing literally thousands of bugs
  60 [21:19] <JFo> so in most cases it is best to file for what you think it is versus just the kernel package :)
  61 [21:20] <JFo> it is always (sadly) easier for other bug supervisors to redirect than it has been for me to do so historically
  62 [21:21] <JFo> we have beaten back the sheer number of bugs in the recent past and I have some things happening that I cannot share yet that will help immensely
  63 [21:21] <JFo> but there is still much to do :)
  64 [21:21] <JFo> I'd like to take a moment and chat about the team
  65 [21:22] <JFo> historically, the linux kernel has been a scary place for non-developers or those hoping to gain insight of the inner workings of the linux kernel
  66 [21:22] <JFo> I can tell you from experience, there should be nothing scary about the Ubuntu Kernel Team
  67 [21:23] <JFo> they are some of the smartest and nicest people I have had the priviledge of working with
  68 [21:23] <JFo> understand, they are very busy, but I have never seen one of them look down on anyone or act in an angry manner to someone who was asking a question or trying to understand
  69 [21:24] <JFo> I have learned more from them since I have been here than in my years of reading and understanding the inner kernel workings
  70 [21:24] <JFo> so, moving on again :)
  71 [21:25] <JFo> The Ubuntu Kernel Team is different from our upstream in that we are 'Distribution Focused'
  72 [21:26] <JFo> this means that we are tasked with providing the most stable kernel possible every 6 months for a release of Ubuntu
  73 [21:26] <JFo> this also has an unfortunate side-effect of keeping us from working on very many bugs in the upstream kernel
  74 [21:27] <JFo> our feedback to upstream has been improving and we have made several major contributions to the upstream kernel, just not as many as the team would like to :)
  75 [21:28] <JFo> there is an ongoing plan to increase what we give back to the upstream maintainers
  76 [21:28] <JFo> so that should continue to improve
  77 [21:28] <JFo> the important designation here is that, in most cases, our bugs appear to go stale from a reporter perspective
  78 [21:29] <JFo> this is not an indication that there is not any work going on to address these issues
  79 [21:29] <JFo> simply that there is not enough opportunity to keep many of them up to date
  80 [21:29] <JFo> this is why you often see me asking for testing updates of issues I know have seen work when it appears that there has been nothing in the comments of the bug itself
  81 [21:30] <ClassBot> Marceau68 asked: I caught myself thinking about that very thing, Ubuntu's release schedule may very well stunt its growth. Too many releases forcing too much maintenance of already superseded software.
  82 [21:30] <JFo> sadly, I can't comment on the release schedule as it is outside my influence
  83 [21:30] <JFo> what I will say is that the 6 month release schedule gives us the opportunity to update kernels without heavy handed changes to userspace
  84 [21:31] <ClassBot> Marceau68 asked: Would you prefer a more spaced out release schedule then?
  85 [21:31] <JFo> I actually don't have an opinion there, as odd as that may sound :)
  86 [21:31] <JFo> I find that we get a great deal accomplished in the time we have
  87 [21:32] <JFo> but any change for less time or more would really make no difference to the team as it stands
  88 [21:32] <ClassBot> Marceau68 asked: Sorry... what is userspace?
  89 [21:32] <JFo> great questions Marceau68 :)
  90 [21:32] <JFo> so, in the kernel there are 2 types of permissions and execution space
  91 [21:32] <JFo> userspace and kernelspace
  92 [21:33] <JFo> this is mainly to provide a deeper level of security within the kernel
  93 [21:33] <JFo> especially as it relates to code execution
  94 [21:34] <JFo> as for a deeper understanding, that will have to wait until my planned triager summit, which I will chat about toward the end of the session :)
  95 [21:34] <JFo> so to conclude this point, we are very different currently than the upstream kernel maintainers
  96 [21:35] <JFo> but in some ways we are growing closer
  97 [21:35] <JFo> as mentioned in the upstream fixes we work on
  98 [21:36] <JFo> now then, I'd like to take most of this session to discuss how you can participate in the kernel community
  99 [21:36] <JFo> I'd also like to chat about some things I have coming up that should help you all participate with your LoCo teams in your areas
 100 [21:37] <JFo> I'll also give you some wiki addresses so that you can research these topics more :)
 101 [21:37] <JFo> As I stated earlier, there is no beginning knowledge level of kernel internals in order to help the team and myself
 102 [21:38] <JFo> we are always looking for more triagers as well as kernel testers and even patch writers, so you see there are all levels that can be attained as you move through your career or even hobby if that is what Ubuntu is for you. :)
 103 [21:39] <JFo> the first place you can look, if you want a deeper knowledge of the type of bugs that get filed against the kernel is in our wiki
 104 [21:39] <JFo> https://wiki.ubuntu.com/Kernel
 105 [21:40] <JFo> one of our current goals for the Maverick development cycle is to update all our wiki information, so keep in mind that these pages are being updated :)
 106 [21:40] <JFo> kernel bug triage information can be found at https://wiki.ubuntu.com/Kernel/BugTriage
 107 [21:41] <JFo> there is a wealth of information on these pages
 108 [21:41] <JFo> as well as our processes for doing things
 109 [21:41] <JFo> if you were interested in how the team works, these are the places to go
 110 [21:41] <JFo> This is another area in which to contribute
 111 [21:42] <JFo> if you see sentence errors or grammar, feel free to edit them :)
 112 [21:42] <JFo> I have also been working on a LiveISO testing image that we will hopefully be releasing this cycle
 113 [21:43] <JFo> it contains a small test suite that can run through a number of kernel tests.
 114 [21:43] <JFo> I'll be demoing that once it is ready :)
 115 [21:43] <JFo> It will be built from the daily Live ISO, so you will get the most up-to-date bits every day.
 116 [21:44] <JFo> the main reason we have yet to release it is due to the late inclusion of a firmware test suite that will enable us to identify bugs in BIOS
 117 [21:44] <JFo> as well as issues with firmware in general
 118 [21:45] <JFo> this will be a great tool to help us move forward with BIoS vendors in getting fixes to their hardware as needed
 119 [21:45] <JFo> once that is in place the ISOs should start building and we can get to the hardcore testing :)
 120 [21:45] <ClassBot> Marceau68 asked: How big a part of what is Ubuntu does the kernel represent? Is it the kernel - Filesystem - gnome - additional applications?
 121 [21:46] <JFo> it is a very large part
 122 [21:46] <JFo> without it there could be no Ubuntu
 123 [21:46] <JFo> the kernel is the core of any OS
 124 [21:46] <JFo> Microsoft has a kernel itself
 125 [21:47] <JFo> it is the key to dealing with the multitude of possible hardware combinations in the wild
 126 [21:48] <JFo> without that problem, I am certain that the kernel would be a much much smaller item :)
 127 [21:48] <ClassBot> yo2boy_ asked: What happens during a Kernel Panic?
 128 [21:48] <JFo> great question yo2boy_
 129 [21:48] <JFo> it depends on what has caused the kernel to panic :)
 130 [21:49] <JFo> most times the kernel will give us a log of what was happening when it panicked
 131 [21:49] <JFo> barring that, we can see in the dmesg logs what was happening immediately prior to the panic'
 132 [21:49] <JFo> in most cases it is due to the kernel receiving input that was not what it expected
 133 [21:50] <ClassBot> tagpaul_ asked: What scheme does Linux use for the memory management in userspace? Is there any code for setting up what page is currently loaded to try and avoid page faults?
 134 [21:50] <ClassBot> There are are 10 minutes remaining in the current session.
 135 [21:51] <JFo> tagpaul_ great question, and one that i am afraid falls outside my knowledge :)
 136 [21:51] <JFo> for that I'd have to defer to one of the team
 137 [21:51] <JFo> as I am under the impression that it sometimes changes between kernels
 138 [21:51] <JFo> but don't quote me on that :-D
 139 === winston is now known as Guest55707
 140 [21:52] <ClassBot> MrSpring asked: thought of adding "don't panic Mr. Mannering" to kernelcode ;)
 141 [21:52] <JFo> hahahaha
 142 [21:52] <JFo> nice
 143 [21:52] <JFo> any other questions?
 144 [21:53] <JFo> have I thoroughly confused you all? :)
 145 [21:53] <JFo> for anything else you all may have, I am always available in the #ubuntu-kernel channel on this server :)
 146 [21:54] <JFo> and I am always glad to help :-D
 147 [21:55] <ClassBot> There are are 5 minutes remaining in the current session.
 148 [21:55] <ClassBot> ech0tk asked: So to sum up, the Kernel is somewhat inbetween HAL and API?
 149 [21:55] <JFo> not necessarily ech0tk
 150 [21:55] <JFo> hal was a part of the kernel
 151 [21:56] <JFo> it's responsibilities were moved to a different tool
 152 [21:56] <JFo> but yes, the kernel is like a huge API
 153 [21:57] <JFo> thanks for all the great questions
 154 [21:57] <JFo> if you are interested in a bit deeper chat
 155 [21:57] <JFo> I'll be givving a session on Wednesday afternoon for Ubuntu Developer week
 156 [21:57] <JFo> this coming wednesday
 157 [21:58] <JFo> thanks everyone :)
 158 [22:01] <pleia2> Thanks JFo!
 159 [22:01] <pleia2> Just a quick reminder to folks that we have a survey for the day, once the day wraps up or you head out if you could take a moment to fill it out it'll help us make the next User Days even better :)

UserDays/07102010/What is a kernel, and why do i need it (last edited 2010-07-10 21:51:32 by alderaan)