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: email@example.com. 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 http://kernel.ubuntu.com/ 20:11 < BenC> More information about the kernel team can be found at https://wiki.ubuntu.com/KernelTeam 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 http://scalability.org/?p=418 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 ? https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129200 20:52 <+BenC> Answering that question would require more time than we have here...my 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!