Ubuntu Open Week - Kernel Team - Ben Collins - Mon, Oct 22, 2007

20:09 < BenC> Hello, and thank you for having me. I'm Ben Collins, the Kernel Team Lead, hired by Canonical to work on Ubuntu.
20:10 < BenC> The Kernel Team handles the Linux Kernel, third-party modules, and other programs related to the kernel (such as initramfs-tools, udev, etc).
20:10 < BenC> Interacting with the kernel team can be done in many ways. The most direct is via IRC on #ubuntu-kernel. We also have a mailing list:
20:10 < zul> win 13
20:11 < BenC> Most of our discussions happen on the mailing list (patches, bug discussions, etc.), with work occurring in the git repo at
20:11 < BenC> More information about the kernel team can be found at
20:12 < BenC> Ok, open to questions now :)
20:13 <@popey>  < mbt> QUESTION:  When troubleshooting the kernel, or drivers within it, upstream devs *insist* on using a vanilla kernel.  What is the best, Ubuntu/Canonical-sanctioned way to do this for the purpose of reproducing "clean" reports for upstream, or should all those go through LP so that the kernel team can work with the upstream devs?
20:14 < BenC> One of the major things we did in gutsy kernel was to trim way down on our patches to the stick kernel
20:14 < BenC> *stock
20:15 < BenC> One thing that has been suggested, and may be discussed for hardy, is a pristine kernel for people to reproduce bugs on, to better work with upstream on fixing it
20:15 < BenC> This would probably be offered through launchpad via a persona-package-archive
20:15 <@popey> < nxvl> QUESTION: to help the kernel team is needed to know kernel development?
20:16 < BenC> Well, to help debug the problems, a good understanding is needed at the very least.
20:17 < BenC> But where we need the most help is bug triaging, which only requires a little knowledge on classifying the bugs and gaining all the needed info for the devs to better handle it
20:17 <@popey> < ubuntu_demon> QUESTION : Does Ubuntu do ASLR (Address space layout randomization) ? If not will something like this be added in the future ? What kind of memory protection techniques does Ubuntu use ? What kind of memory protection techniques will Ubuntu have in the future ?
20:19 < BenC> ASLR was planned, but because of compatibility issues, we could not enable it
20:19 < BenC> For hardy, we plan to look at stack protection for x86_64 at least, and ASLR being enabled
20:20 < BenC> These things are being driven mostly by the security and server teams (but obviously benefit desktop as well)
20:20 <@popey> < evarlast> QUESTION: what is the kernel team doing to ensure that the kernel performs well on computationally intese systems?  See
20:21 < BenC> Short answer to that is "nothing" :)
20:21 < BenC> Our main focus has been the areas that the majority of our users want, which so far has been desktop/laptop, and on the server (generic servers)
20:22 < BenC> If community efforts can drive interest in this area, then it's something we will work with more
20:22 <@popey> < ikonia> Quesstion: What is the decision process for backport's of current kernel release to current ubuntu packaged kernel
20:22 < BenC> I'm not exactly sure of the question, but I suspect you mean something like 2.6.23 on gutsy
20:23 < BenC> and the decision process is, we have too much work to get hardy done, there's no way we can spend our time on a new kernel for gutsy
20:23 < BenC> Since it's only 6 months till the next release, it doesn't make much sense
20:23 -!- mode/#ubuntu-classroom [+v BenC] by Mez
20:24 <+BenC> We have considered such things for LTS releases, but so far have decided against it due to the incompatibilities with old userspace and new kernels
20:24 < ikonia> BenC: apologies, the question was badley worded. I was aiming to ask "what is the driver for backporting fixes/improvments from the current release kernel to the current ubuntu packaged kernel - keeping in mind the effort involved. Is is straight effort V Benifits or is it driven by demand. This is more relvenent on LTS releases
20:25 <+BenC> For the most part, we only backport security fixes, and major fixes (which hopefully don't exist at release time :)
20:25 < ikonia> thank you
20:25 <@popey> < BonesolTeraDyne> QUESTION: How do you choose what modules are loaded with the default kernel that's included with the CDs, and what should be left for installation by the user?
20:26 <+BenC> We don't choose
20:26 <+BenC> The kernel decides based on what hardware it finds
20:26 <+BenC> if you have the device and we have the driver, the driver gets loaded (except in cases like restricted modules, such as nvidia)
20:27 <+BenC> Or maybe you are asking about what modules we include with the CD
20:27 < BonesolTeraDyne> Yes, how do you determine what modules come with the CD
20:27 <+BenC> BonesolTeraDyne: is this a question of what is loaded (as in modprobe) or what we make available (as in packaging)?
20:27 <+BenC> Ok
20:28 <+BenC> The CD just includes all the modules that we compile in the kernel, and the third-party modules (linux-ubuntu-modules, linux-restricted-modules)
20:29 <+BenC> Our aim is to include as many drivers as possible, where it makes sense
20:29 <@popey> < evarlast> QUESTION: Will KExec ever be an option so that we can reboot without POST?
20:29 < BonesolTeraDyne> thank you
20:29 <+BenC> I'm pretty sure the kexec package includes an init script to handle that already
20:30 <+BenC> Whether it will be enabled by default or not is unknown
20:30 <+BenC> some drivers do not de-initialize hardware properly, and a kexec to a new kernel can fail easily in these cases
20:31 <@popey> < PwrKroll> QUESTION: Is there anything you feel the Kernel is missing so far, and if so, what, and future plans?
20:31 <+BenC> The only thing that quickly comes to mind is a stable 802.11 API :)
20:32 <+BenC> upstream wireless-dev is handling that, we are helping as much as possible
20:32 <@popey> < Linuturk> QUESTION: What is currently in development to improve batterlife on mobile computers (ie laptops, tablets)?
20:32 < PwrKroll> thank you
20:32 < Linuturk> battery life*
20:33 <+BenC> Intel is doing a lot of work in this area, especially with the powertop utility
20:33 < Linuturk> I've noticed that the powertop changes it suggests do not stick.
20:33 <+BenC> Integrating a lot of the work that came from this project, and starting a baseline for improvement during hardy is going to be discussed at UDS
20:34 <+BenC> One of the kernel team developers (amitk) will be in charge of this effort
20:34 <@popey> < ikonia> Question: What is the current development model with regard to kernel headers, more so now the the distro wide sanitisezed headers (LLC) project is in effect Dead
20:35 <+BenC> That project is dead because the stock kernel now has a headers target that installs sanitized headers direct from the source tree
20:35 <+BenC> we've been using this to create the linux-libc-dev package since feisty
20:35 < ikonia> that was teh response I was looking for, thank you
20:36 <@popey> combining two questions:-
20:36 <@popey> < ikonia> Question: How do you feel the ubuntu packaged kernels has progressed with the current LIBATA branch - has UUID worked out as expected
20:36 <@popey> < ikonia> Question: What as the driver to adopt UUID so early when in most peoples mind it was so early from being the norm
20:36 <+BenC> libata has turned out to be a real pain, but at the same time a real win for us overall
20:37 <+BenC> most new chipsets are being supported in libata, and not in ide (for pata)
20:37 < alexlafreniere> hi
20:37 < alexlafreniere> whats goin on
20:37 <@popey> alexlafreniere: chat is in #ubuntu-classroom-chat
20:37 <@popey> < zul> QUESTION: what is required for a patch from launchpad to be accepted?
20:37 < alexlafreniere> sorry
20:37 <+BenC> The UUID change was in preparation for this change
20:37 <@popey> sorry BenC 
20:37 < ikonia> BenC: that makes sense. Sensible response, thank you
20:38 <+BenC> popey: np
20:38 <@popey> zuls question is next
20:38 <+BenC> zul: Basically, patches need to be approved by two kernel devs
20:38 <+BenC> if the patch is marked as such in lp, we'll see it and review it (as opposed to just being an attachment)
20:39 <@popey> < ikonia> What is the selection point for a kernel for a new release, is it just "current" at start time of the project and then it sticks, or is there normally a wait for X feature
20:40 <+BenC> The upstream kernel is on roughly a 3 month release cycle
20:40 <+BenC> Since dapper, we've tried to decide on the kernel version that would release no later than 3 months before our planned release
20:41 <+BenC> So for Hardy, that should be 2.6.24, but we will evaluate that decision at UDS to see what features are planned for 2.6.24, to make sure we don't take anything that may be very unstable
20:41 <@popey> < ttread> QUESTION: Since on an installed system the hardware doesn't change often, could the modprobe at bootup be optimized or eliminated to reduce bootup time?
20:41 <+BenC> Well, it can't be eliminated :)
20:42 <+BenC> There are probably things that could be done to speed up the process (perhaps pre-load modules instead of waiting for device detection)
20:42 <+BenC> Other things that come to mind are pre-linking, like what OSX does
20:43 <+BenC> charting the time there could be good for seeing if there really is anything to gain
20:43 <@popey> < ikonia> Question: How do you deal with ubuntu specific patches and the effects on the kernel at development packaging time. Gcc and binutils is a famous issues with Fedora based distro's, do you aim for vanilla compatability and work towards that, or do you aim towards version compatability and patch towards that
20:44 <+BenC> The good thing about the toolchain is we can use which ever version we want...doesn't have to match the userspace version
20:44 <+BenC> we haven't had a reason to do this, since we try to keep things in sync, but we're not locked down either
20:45 <+BenC> As for our aim, since inter-distro binary-compatibility for the kernel is non-existent anywhere, we don't aim for that sort of compatibility
20:46 < ikonia> thank you
20:46 <@popey> < ubuntu_demon> QUESTION: What kind of kernel related security stuff can we look forward to (other than the already mentioned ASLR and stack protection for x86_64) ?
20:46 <+BenC> There's AppArmor, which just released with gutsy
20:46 <+BenC> I think we plan to extend support for that in Hardy
20:47 <+BenC> I realize that's more userspace protection, but it's provided by the kernel :)
20:47 <+BenC> protecting userspace is likely the best line of defense, IMO, since it's the main entry point to root access
20:48 <+BenC> but we're always open to suggestions
20:48 <@popey> < ubuntu_demon> QUESTION: How mature is the iwlwifi driver ? When (which Ubuntu release) do you think it will be mature enough to start recommending average users to buy ipw4965 ?
20:48 <+BenC> Uh, gutsy :)
20:48 <+BenC> iwl4965 (from the iwlwifi driver) is already there
20:49 <+BenC> In fact, I'm using it right now
20:49 < makiolo> test tak ...
20:49 <@popey> < nixternal> QUESTION: does Ben's servers really set out in a barn, secured by electrical wire? :p
20:49 < makiolo> sorry
20:49 < Tesla-HETy> BenC: it does not answers the question really
20:50 <@popey> chat in #ubuntu-classroom-chat please
20:50 <+BenC> Tesla-HETy: basically it does, because I would not be using it if it wasn't stable :)
20:50 < Tesla-HETy> ok. ty
20:51 <+BenC> nixternal: Yes, there is over $100k USD worth of server equipment in my barn, protected by cows and electrical fence :)
20:51 < nixternal> haha, good times!
20:51 <@popey> < ubuntu_demon> QUESTION : the kernel can't reach C3 and C4 (powertop doesn't show C3 and C4). Will this be fixed for Hardy ?
20:52 <+BenC> Answering that question would require more time than we have first impression would be that the hw doesn't support it.
20:52 <@popey> < ikonia> Question: While I appriciate the hassle and pain of supporting and building multiple kernel versions for the same release (I'm not talking archs) is there not a need starting to arise for more custom kernels such as the LL kernel required for ubuntu studio
20:53 <+BenC> There is a need, and we support those needs (realtime, xen, lpia, ...)
20:53 < ikonia> fair enough
20:54 <+BenC> However, supporting multiple kernel flavours for the main platform (e.g. multiple desktop and server kernels) is not something we want to get in to
20:54 <+BenC> e.g., we used to have 386, 686, 686-smp, k7, k7-smp
20:54 <+BenC> we wont do that again
20:54 <@popey> < ikonia> Question: with ubuntus populatirty in my opinion being driven by desktop effects / laptop users as a general rule, do you feel that advancment features of the kernel are not being exploited enough/quick enough due to focus appearing to be aimed at usability
20:55 < ikonia> BenC: thats good to hear
20:55 < ubuntu_demon> BenC : regarding C3/C4 my hardware does support it (intel Core Duo T2500). The bug is confirmed. I don't know what hardware is affected. I understand that you don't have time to go into it further right now.
20:56 <+BenC> Yes, I did used to worry about that...but we've been making a huge investment recently in building a server team, and taking advantage of some of the more advanced features related to that target
20:56 <@popey> < aditya> QUESTION: Is there any way to load per user modules into the kernel (eg. user 'abc' loads fuse module to be accessible only by him) Or is some work being done on this?
20:56 < ikonia> BenC: music to my ears, thank you
20:57 <+BenC> Nope, no such support exists
20:57 < aditya> BenC: any work being done in this direction?
20:57 <+BenC> not that I'm aware of
20:58 < aditya> ok. ty
20:58 <@popey> < ikonia> Question: What is your toolchain used for building initial ubuntu releases, more so around the kernel, is it a specific sanitised tool chain, or a toolchain that is exactly the same as the release the user would get
20:58 <+BenC> If you check the release schedule, the first step is always a new toolchain, and usually that toolchain persists throughout the entire development cycle
20:59 < ikonia> I've seen the toolchain at early stage, nice to know its followed though
20:59 <+BenC> We have a tool chain person that handles that, and one of the initial steps is to make sure that the base system compiles with it (and this includes a new kernel)
20:59 <@popey> < Yasumoto> QUESTION: this may be a bit basic, but I've been starting to work on compiling a kernel. do you guys recommend using an ubuntu-specific one, or can I just use a vanilla kernel?
21:00 <+BenC> you can use whatever you like, we don't support self-compiled kernels any way :)
21:00 <+BenC> Which source tree you use depends greatly on why you are going through the pain of compiling it yourself
21:00 <@popey> < ikonia> Question: With more and more drive been given to userspace are you trying to focus any ubuntu features tools at really utilising this new found userspace power, an obvious example is your inclusion of fuse
21:01 < Yasumoto> haha, alright, fair enough. (mainly just to learn how it works together) thanks
21:01 <+BenC> The kernel team really doesn't focus on this, but the rest of the distro team does, and they are driven by blueprints on launchpad
21:02 <@popey> < evarlast> QUESTION: any change of SELinux becoming default or moving more to the forefront like in Fedora?
21:02 <+BenC> As far as I can tell, AppArmor is going to be preferred for this
21:03 <+BenC> There are some documents on the wiki explaining apparmor-vs-selinux
21:03 <@popey> < ikonia> Question: Are you gonverned by any restrictions, such as physical space/size for the kernel at package sizing, and does this effect any features, as not all functions are modular
21:04 <+BenC> The kernel itself is well under the size restrictions, which are architecture dependent
21:04 < ikonia> so its arch depentant - not self imposed
21:04 <+BenC> generally features are not restricted by this size
21:05 <@popey> < ikonia> Question: would it be fair to say that the kernel team was a reasonable portion of the decision to drop some external archs such as PPC
21:05 <@popey> < ikonia> Question: follow on - how does the partnership with Sun for Sparc effect the progress of the x86/x86_64 development progress within ubuntu
21:05 < ikonia> thanks
21:05 <+BenC> No, kernel had nothing to do with dropping PPC
21:06 <@popey> We're pretty much out of time now..
21:06 <+BenC> Yeah, sorry, last question would be pretty lengthy too :)
21:06 < ikonia> thats fair enough
21:06 <@popey> fantastic session, well done BenC !
21:07 <+BenC> Thanks for having me
21:07 < ubuntu_demon> thanks :)
21:07 < Tesla-HETy> BenC: thanks
21:07 < BonesolTeraDyne> Thanks
21:07 < LjL-Temp> thanks
21:07 < ikonia> BenC: enjoyed, thanks
21:07 < aditya> Thank you
21:07 < alexlafreniere> Thanks for your time BenC!

MeetingLogs/openweekgutsy/KernelTeam (last edited 2008-08-06 17:00:39 by localhost)