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)