 So actually I'll just let you guys introduce yourself if that's okay. My name is Dan Frazier most of the work I do on the kernel team is I-64 port work Hello So my name is Sven Lutter and I'm in charge of the port PC port of the kernel I'm Holmes. I work primarily on the two full kernel and security updates facade Hi, I'm Josh Kwan and I work on spark 2.4 2 6 and As well as do helping Holmes out with I 386 stuff when I can Hello Hello. Hi, I'm Andres Salomon. I work on two six kernels I 386 stuff and sometimes security stuff So yeah, we'll just take a few minutes break Okay, good so this head right before the two minutes. My name is Dan Frazier Most of my responsibilities are around the I-64 port So the outline of this talk is I'm going to give a little bit of history about How the Debbie and Colonel team came to be about a year ago An overview of who we are and the kind of stuff we're doing today A discussion about Debbie and patches, you know the kind of stuff we accept into the kernel stuff we reject and why stuff we're working on for the edge release and Stuff you guys can do to help should you want to So I'll start with this Herbert zoo was The king of kernels for I don't know how long whenever I start on the Debbie and project. He was maintaining the kernel source package Every release Herbert you know did a lot of great work and he was very responsive to bug reports very responsive to security as far as I could ever see But you know about a year ago, I guess this was May of last year. He chose to retire And resigned from the project and that left a big gap So this little timeline of what happened about that time so May 4th last year Herbert decided to retire The next day Andres proposed that maybe we do a kernel team citing the known team is a successful example of a team the Debbie and project TBM announces a tent to form its kernel team About two weeks later. I guess Wli William Lee or when the third Announces intent to in a new kernel packages, you know kind of before the kernel team was actually announced but that was just four days later and he did a first in a view of The kernel source stuff just changing the maintainer over on June 15. So as you can see this this all happened pretty quickly and got going So some of the initial challenges and I wasn't really present a lot of this Going back and looking at mailing lists Was understanding a lot of the existing patches So if you looked at a kernel source package from like the woody time frame You would see just a bunch of monolithic kernel patches one for each release He patches were split up by functionality and it was you know unclear about why certain things were in there so I remember a Christoph Hellwig and probably a lot of your work to going through all the different patches splitting them up Figuring out what needs to go upstream what we should drop What not and that that took quite a bit of time Then version sync was a big issue. So if you look back at the woody time frame Since Herbert was doing x86 and alpha stuff You would see that those would track the kernel source releases as they would come out very quickly Other architectures and I was doing some I-64 stuff at the time So I remember like having to just kind of pull his page to see when new kernel source was being updated Security release comes out, you know and unstable It wasn't there was no notification to the other porters that you need to rebuild against this later version for security fix So, you know versions got out of sync pretty quickly that way I-64 would be like a version or two behind just because we didn't know there was something new and So you know all their architectures had to track the source independently so in the woody time frame You know we had a 2 to 10 kernel source tree for power PC AP us 2 to 19 for arm 2 to 20 from 68k power PC and spark 2 to 22 for alpha 2 4 16 for x86 an arm 2 4 17 for us through 90 power PC AP us and MIPS 2 4 18 for alpha I-36 and power PC to 4 19 for MIPS and some architectures didn't even use kernel source Those were HPPA and I-64 I think at the time So as you can see this is pretty ridiculous and you know If you hadn't noticed there hasn't been a kernel security update to woody in some time And I'll bet you this is why doing a single patch into woody to fix a security update across all sources Means a rebuild of all these kernel source packages the porting effort that that requires and they're rebuilding all these architectures against it pretty pretty insane So there's a total of 10 kernel source packages that time All sitting in woody or still are So here's an overview of the kernel team Debbie developers and non Debbie developers. I think everybody here is a Debbie developer There was also William Lee Irwin and Kristoff Hellwig, which I don't think are Debbie developers, but they're very active Oh and Irwin What's this? Oh Yuri Smarkov. Oh, yeah, I'm Frederick Shuler. Right, right, right. So there's a lot of other people, but So We maintain a number of kernel packages the kernel source stuff and the kernel image stuff But we don't do everything right now that everybody on the kernel team is concentrating on Linux stuff There's no free BSD. There's no herd on the kernel team An arm in 68k are maintained outside of the kernel team. Although I saw the arm guy is here Hello, and it looked like you were joining the kernel team today or looking into it. So awesome Come on down if you want no, okay and We also do the maintenance of currently related packages if you look in our subversion tree, you'll see stuff like Internet Rd tools crown FS and make them linus You guys just jump in if you have anything to say So I'll go over some of the stuff where we're currently doing One thing we need to do often is work with a Debian installer team The Debian how many of you guys know about you dubs and how the Debian installers built up? Okay, so that's about I'd say half the people So the kernel image is a very monolithic package I mean it provides kernel modules But it has all the modules and the kernel image all in one big kernel image package Di is a I missed your correction. It's a highly granular System for a highly modular installer So we take the kernel image and we actually split modules into different Logical groups, so you'll have the XFS modules for the XFS file system You'll have a set of scuzzy modules the scuzzy core modules, which are what we consider the most popular Scuzzy modules you might want on a system So we take that kernel image and we have a build dependency on it to this little Or this links kernel DI package has a build dependency on that package Where it copies all the modules from the system into separate small UW components So that way with the Debian installer you can build a custom Debian install image that has XFS support By providing you know just the UW you need for XFS that way you can make it fit on you know a floppy or whatever so this transformation right here is a Mechanism for doing that. So you'll see links kernel DI packages in the archive This makes version sync problematic because if we have a 268 Version 3 version of a package and then we build Linux kernel DI from that We kind of need to have that both those things in the archive to satisfy GPL requirements But if we actually do something like update the 268 3 to 268 4 now DI is out of sync and And you know even worse than that and I'll get into a bi step more later But if the a bi changes then the package name changes There's a lot of conflicts that are brought up there So security is something that the kernel team handles for unstable and testing Horms is a lot of that work There's nobody on our team that's currently on Vindersack. So we don't you know similar to the testing Security team. We don't monitor Vindersack. We don't have We don't recognize stuff that hasn't come through a public channel yet But we do get security reports from various places including the testing security team I've seen the in boot two people give us lists of stuff. Where are the places do you get? Okay upstream stable trim so a lot of monitoring goes on there, but Really we count on users it seems to give us bug reports to which we can respond and patch stuff Horms is currently maintaining a security branch for Sarge But what's unclear to me is whether or not the security team will actually use that as that been decided Okay, so that's something that's very unclear right now Okay, sorry Sure, so he asked whether or not the security branch is actually going to be used by the security team and We have no idea Yeah, basically, we're hoping if we can get it up to scratch and then it'll be something that they want to use but Right now the security team in particularly Joe is very busy. So he's very hard to get in contact with So so right now we're not really sure if our team is doing a stable security support But but we're maintaining a branch just in case So a bi changes and why they suck And they do a change in the kernel an a bi change You know as a change in the kernel module a bi so something that changes an interface that would make your modules no longer be able to load Once you upgrade to the new kernel This is something that upstream Colonel that are people definitely do not guarantee They have a file called stable API nonsense in the kernel source tree which describes Why a bi and API changes? Aren't guaranteed and aren't necessarily a good thing for the kernel. They state reasons like Changing an interface will actually explicitly force people to update their interfaces and make sure that those are secure and Issues with maintaining back risk compatibility and not willing to waste kernel developments time with it We didn't or if you look at a kernel image source or kernel image binary package name You'll see the a bi encoded right after the upstream kernel name So right here you see 268 dash 2 so this is the second a bi role of the 268 kernel for 686 Often you know if you're running storage or something and you want to run a stable kernel You'll just want to be able to run app get update app get upgrade and track that for that purpose We provide a meta package My kernel image 266 86 so if you have that installed on your system and you have to get dist upgrade If the a bi changes you'll follow along with it. So in dash 3 comes out. You'll get the upgrade. Yes How do we actually check for the a bi changes Dylan Yeah, so he's asking how do we know when the a bi changes And as the also maintainer kind of sucks when all of a sudden his modules don't load in a kernel anymore So I don't think we have an automated process at this point. I know that you wrote a script that can check and examine that Ubuntu is actually using the script right now. We're working on a single source packaging and That script will be in there as well So I have some scripts that I run which basically compare It actually just does a diff on the system map and I run that before I upload kernel sources So if you see kernel sources uploaded by me and chances are they don't have an a bi change You weren't expecting that that's not always the case I have I saw something to say about that I feel that all the people like you which maintain third-party modules should integrate more with the kernel team and have some My my intention is that we have some infrastructure in case of a new kernel upload There is an abh change we know about it and we trigger an automated or semi-automated rebuild of all the externals Kernel module which means that you will have should maintain your as a modules inside or other modules inside the subversion repository or a separate Subversion repository or some infrastructure which will allows to do automated new builds I have sent some some mail about this to the kernel Baby and kernel mailing list, but it was mostly ignored So I hope this will change Yes, okay Well, you could have Okay, so but for the other module maintainers it will be great if we cooperated and maybe you will have some as a Out of CVS or whatever Just to paint the picture of the whole a bi change thing a little better Well, for example the last big time it happened and we had all of this DI suckage as a result it was just because of security fix which I believe it was related to What's that the TTY locking stuff? Yeah, so when a struck changes and obviously when a variable Disappears or is renamed and stuff like that That's what causes the a bi change to prevent modest from being from resolving the symbols and loading Yeah, so I just wanted to make sure people understood what it actually was the last time this happened was particularly problematic because It was problematic because firstly we didn't see it coming But the thing that made it really hurt was it was a change essentially to the task struct Which basically mean almost every symbol changed so it wasn't like a couple of modules broken. It was everything bro Yeah, right now. We're in a situation where there's a pinning security fix That you will change the a bi that we just can't get in yet because Of issues with the with devian installer. So I get to that in a second. So one issue With the with the a bi changes is that it changes the package name So kernel image 2682 becomes 3 so that forces us through new so when we're doing this right about release time We need to get all these architectures rebuilt Uploaded into incoming and then they off the pin new and so that has its normal delay It's not kind of slows stuff down a bit But also what the package name change is that it breaks an interface with the I di has inside each release A list of kernel image names that I shouldn't you know suggest as installations or the stuff. It actually uses as an install kernel Once you change that then it can no longer down down download udabs from a mirror and pull The proper version so you can't have a dash to Version a di running a dash to a bi of a kernel pull down the dash three version of the modules They just won't load and that's intentional So this sucks for di and that also and that makes it so we can't really have a Cohesive way to upload new a bi changes. Hopefully security at demi.org Won't have this restriction because in theory you can install with the I Upgrade to the latest version in stable and then pull a new a bi version over from security at demi.org But that also means that when we do point releases and stuff that we need to spin di so I'm going to go on to an overview of Debian patches the kind of stuff that we provide in Debian and what we don't So kind of patches the kernel team likes is stuff like security fixes driver fixes and stability fixes These are all things that are in theory upstreamable Things that make our users lives better. You know, there's really there's really no reason to say no to these things But those patches we generally reject is stuff like new features You want the latest version of software suspend that has been accepted upstream? It's probably a reason has been accepted upstream So we try not to keep that out of there We also don't want to maintain interfaces that may change before they actually get it accepted upstream Stuff like attitude drivers same situation if the driver hasn't been submitted upstream Who knows how long it's gonna last or who's gonna be maintaining it We don't want to provide something for users and then take it away later And even worse than that would be maintaining it ourselves after the fact and You know, just just your favorite patch set, you know, whatever. It's not something that Needs to go into the Debian kernel. So pretty much, you know, if you really think this patch should be some put into Debian submit it upstream submit it to colonel.org let people review it Get it accepted into a later version I've often seen these guys backport fixes or new bits of functionality from later versions that our users want As long as we know that there's a forward path for it So going on Sarge is now done. What do we do about 2.4? This is a big question that Horms has right now Can we drop 2.4 from sit and testing if we could it would make our lives significantly better We'd be able to ditch in our d-tools in theory because in a ramifest is up and coming If you guys haven't looked at the inner d-tools source code, how many of you have how many of you have seen it already tools? Yeah, so it's It's very horrible. It's this huge huge piece of shell You say something I was just going to ask how many of you wish you hadn't Saxony Right Yeah, so his comment is is that he works with herbert and this is the kind of stuff herbert does is write huge bits Of shell code to do stuff when it could be like 10 lines in pearl Yeah, and I I learned a lot from reading herbert shell code He uses a lot of stuff that I've just never seen before and have to figure out What's that? Yeah Yeah, I remember when I took over i64 packaging I went on and I just created my own set of packages Because I could not understand what he was doing over the period of the next year I would gradually figure out. Oh, that's what he was doing back here and pull out bit of code back in And over time I just essentially went back to what he had. I just now understood it So it's less if I don't have Okay, so It'd be great if we could ditch internet e-tools problems with going to a two four kernel is that nips doesn't have a two six currently up It has I guess upstream just hasn't been ported forward and you were saying the spark 32 s and p sucks and two six It's just completely broken Yeah, and um, there's talk of actually Because of the advantages for all the rest of the architectures Migrating to two six There's a just emotion to just drop the whole s and p thing because heck your toaster is probably faster these days anyway My spark 32 is best served as a monitor stand right now Grant was asking for an example of a multi-way spark 32 box and you said spark 3000 So are there other issues with two six that you guys are aware of or two four They're the main I wasn't aware of the spot problem, but mips one is the main issue. I'm considering right now Well, basically the only thing reason I'm considering doing two four at all Um, basically my consideration is that by the time we get round to doing edge Anyone who can be using two six probably will be and so two four is going to be pretty marginal As one more data point and Sven Luther, maybe there was a little bit about this I followed the m 68k build and devian 68k lists um At one point there was an m 68k sub arch that had trouble With two six as well. Has that been addressed or is that another case of just digit? I don't remember which one probably I mean this slide is really we're trying to open a discussion about this Which will go beyond this uh presentation if Wouter sir, maybe he can tell us He's right here There is work on uh, two dot six from six. Okay, but uh, last time checked. It's not really stable yet on Most sub architectures, they're working on it But they're working it for quite long now and I'm not really Sure, what's going to happen with it? But yeah Not not really yet most sub architectures support, uh, two four in fact all sub architectures except for mac Support two four very well Two dot six is not not really yet. I think All right, thanks And on on the poor pc side, we we still need uh 2.4 for the apus port. I took simon is working on it and I had some nubus patch that nobody tested Yet, which is not yet ported to 2.6 and we have also some problem with the old world miboot Miboot yes miboot Installation method so but that are very minor problems and we could drop them because Apus I believe apart from simon nobody's using it anymore and uh the same for the other architectures sub architect So there's likely going to be problems with di as well because you know devafest is now deprecated in two two six kernels So I have a feeling they're going to want to do something, you know That doesn't rely some sort of hybrid detection that no one relies on devafest Is and that kind of leaves us with sysafest and stuff like that that's only in two six so It would be great to get rid of it get rid of 2.4 That's a lot of stuff that's been happening lately. I've seen andris and Yuri working on quite a bit on irc is moving to a single source package right now there's a Right now building a kernel is multiple layers. There's a kernel source package that we start with and we all share as a base Then from there some architectures have kernel patch packages specific to their architecture Um, that's pretty much gone away in a lot of cases with two six Then there's also the image build on top of that. So we we have multiple layers um What we're moving to now is going to a single source package So that you have one one package that you build on different architectures and the kernel images are split out there This will help keep a lot of things in sync. It'll let the build these do the work that we've all been doing by hand as porters Um, and we'll still provide the kernel tree for external architectures, which I guess there's just one now, but The kernel tree mechanism How many people here are familiar with kernel tree versus kernel source? Do you know the differences? Very few so I'll I'll go through that in a second And one other thing this single source package will give us the opportunity to do is actually rename the package to linux kernel because We may no longer be the only kernel in debian for much longer So with with that, let me give you guys a brief like, uh, do you have a kernel source installed here kernel tree? Oh, well, okay, so let me go on to the next slide and then I'll let me check Sure go for it I know it's installed there Um, oh non-free firmware is a slide. I just added because I'd forgotten about it. Um, one issue we're working on right now is There there's various dfsg non-compliant bits of firmware in the kernel source tg3 is the best example that most people familiar with your question About the linux kernel for a name. Is that uh, I already decided it means going to be linux kernel or It's gonna be oh go ahead. Not quite. We had a discussion about it. Um, and Basically, we're talking about the source package name calling it linux dash two six And then the binary packages linux image two six twelve or whatever Although yeah, but we need more discussion about that I'm just asking because I maintain the glumach pistachio and I'm part of the k3bsd team So it will be nice to unify the the the name for all kernels in debian. So If it's not yet, I mean if it's decided, uh, I like to to to change the The names of the other packages you should are you subscribed to debi? No, what I should I know Yeah, we should probably discuss on debi kernel. Yeah, sure. Okay. Yeah, maybe at some point we can have like debi and cross os kernel list or something too so that you don't have to see all the noise on debi kernel um All right, so non-free firmware. So Um, how many guys are familiar with the with the binary blob? Do you know what that is? Okay, that's most everybody here So binary blob is just a dump of hexadecimal and a dot h file or a dot c file Um, that is actually a compiled code Compiled blob of firmware Obviously, that's not dfsg free if you consider that that firmware as the software that's under the dfsg so What we've been doing so far is uh Going ahead and shipping it in sarge sarge we left all that firmware in there But now undress has been working on a kernel modules non-free package Where all the modules that can be redistributed Live So so they're non-free but distributable and that's a fine line there so The difference there is that uh, non redistributable stuff Is stuff that we haven't given permission to even send out to our users You can usually tell by looking at the license go ahead. There's about eight drivers in the current Linux kernel tree that are non-distributable Because of their firmware for those of you that use the tg3 driver You'll notice that initially the firmware was stripped because we could not distribute it At all do the licensing We've resolved that with two six twelve so that one will be going back in But there are still six or seven more that we need to work on to get permission to distribute So, um, undress and Spin some as well been working with the copyright holders upstream to get that permission And actually get patches upstream into the kernel source that changed the licensing to explicitly say that the stuff is redistributable It still doesn't make it free by debbing his definitions, but we can at least put it in the non-free repository That'll of course have implications with di because if you need the tg3 driver to install Then therefore you need to have some you deb of these non-free kernels as well On the media. Yes There's a wiki page here that these guys put together that list kind of the current status of where Where we are with each of these copyright holders And which drivers are currently in this non-free section, which ones? are not Init ramifest is something that jeff bailey's been working on from buntu How many people know what in it ramifest is? Okay, so it's about half again It's a new feature in two six, which is A replacement for in an rd and it tends to replace in an rd in an rd is a symbol block device Or a symbol block file system I would say right a block file with a file system on it that has All the modules and stuff you need for booting and that's what the inner rd tools creates for you when you install a kernel In a in a ramifest doesn't require file system code at all. It's a cpio archive. It's kind of tagged on to your kernel image So right now we have cramifest has to be installed in every kernel It has to be loaded all the time, but we'll be able to drop that if we do this Unpacking happens early early enough to say Load firmware should you need it for your sketchy device or whatever These things are actually stackable so you can have multiple In a ramifest cpio archives tagged together and they'll just overlay on top of each other as you load Some stuff i'm not too familiar with but magic root dev naming goes away I remember they used to do stuff with dev root that I didn't understand the shell But now the name scheme is going to be the same before boot and and during boot Um And right now the way in a ramifest works or did whenever I put together this paper Was it had hot plug in udev built inside? And it just had all the modules that you need You could possibly need to boot and let's hot plug in udev You know go about its business of Doing hardware discovery the same way it would if you were booting into a normal system That works well from boot 2 because I think they have you know memory requirements that aren't as stringent as some of the Debian's users will be So we don't know if that'll work for us or not. Do you guys know if there's been any Discussion about that So i'm not sure what we'll do for devion as far as hardware discovery and stuff It'd be ideal that if we don't have to do the nrd tools thing of Creating an nrd image in the post install. It'd be awesome if we just have it all prepackaged That would take away a lot of the differences between installations And bugs and bugs So harm said about half the bugs we see is related to nrd tools right now And we get a lot of bugs so that's that's a big number And the uber feature of this is that it may just get a bit of nrd tools for us if we can get rid of 2 4 Uh, what can you do to help? So a lot of people in the devion community. I'm sure just run your own kernel But if we can get more people testing the devion kernels before we do a release We have a question sure In response to that patch you just mentioned which looks quite interesting. I do have one question The current average kernel size right now for the normal kernel not the boot up kernel for di Is around 15 megs, which is already fairly huge in my opinion And by the time you had the built-in udev and hotplug implementation We're probably going to be getting closer to 20 megs right and that to me the Default deep in kernel size is a big concern because I get to do a lot of installation on hardware that has Extremely limited size for the boot partition for instance So I'd like to your your feedback on how you intend on keeping the kernel size to more reasonable And ideally shrinking it from its current size Can I apply to that so first What you are mentioning is not really the kernel size plus the kernel plus in eternity size And the only reason it's growing so fast for you is that you are you are using In the slash etc slash mkineeterd slash mkineeterd.com file You have modules equal most the default which will put most modules in it and make you a huge huge huge Uh In eternity, which is the problem the same thing is to change to modules equal depth Which makes a much more reasonably say that module The the not not so good and okay the problem with that is that The intel people or the main kernel people they don't like it to do that because they were not sure it will not break in some case And we had history going on and in eternity tools were not so nice and stuff like that So it is possible to have reduced kernel size on per pc We will kernel which fits in four megabytes Including the in eternity and there is no major problem I don't know how it will scale with the in it any tram fs stuff But it may be a problem Okay Yeah, I wanted to ask about can you hear me? If you guys had any thoughts about dealing with Out of tree kernel patches, um, I deal with two kind of intrusive kernel patch packages and It's for the user There's kind of a high barrier for actually using those patches because you have to download the patch Applied to the kernels kernel source and then build a kernel your own kernel So you can't really track the kernel images as easily So i'm kind of curious if you guys have any thoughts about how to Um, make that process a little easier for the users I know one thing I could do is with a kernel patch is build images And then users could install those image packages, but that's kind of a pain and um I don't know if there's any thoughts about making module assistant type interface for kernel patches or I was actually going to mention module assistant. Um, that is something I would like to do in the long term Is to get an interface like that to both manage Um currently installed kernels as well as external modules that are compiled against it and kernel patch packages I've brought it up before but Until we get the single kernel source Thing worked at we recall kind of you know struggling to just keep up at this point. So that should uh, That should allow us to get some free time to work on such things So this is a follow-up to mika's question. Um, I'm the maintainer of the suspend two kernel patches now whether you guys like that It seems to be Bit of a problematic issue. Anyway, um, we were thinking about working on converting it all to modules so that we can actually Integrate this with the running kernel, which would kind of solve this problem I'm wondering whether you guys have experienced with that and whether um, this Would be possible on a generic level or whether this is going to be really hard to do for the Average kernel patch. So there's a question around like maybe having an upgrade automatically build a set of modules Well, not really no, I'm A kernel patch changes the source and then has to be with recompile the kernel module Replaces it's monkey patching in some ways it replaces parts of the code With other implementations and you could in theory replace those parts that you actually patched with separate Function calls that you load from modules so that the functionality comes from modules Which you can then insert into the kernel images that you provide rather than having expecting the users to Build their own kernel images after applying the patch Well, not that I've any useful information on this, but that would be cool. That's you're basically talking about adding kernel hooks for modules for like functions that aren't impaired for that sort of Well, lack of a better word intrusion uh, so I think this is the kind of feature that we would like you to submit a patch for Yeah, I'll have it up by tomorrow. Thank you I think we have time for just one more Maybe too much Okay, there is a small question about the real-time patches, these normal patches And I know that they have resulted in upstreams and there has to be a lot of these customy kernel mailing lists about the real-time patches And I think that they have been most effective because They improve a lot of Rismo's time in interacting with the application, but they may be forced one or two percent They not be forced on web server applications And I also know that because they have a deeply internal failure They can't be so easily applied by normal users So is there really any discussion about this real-time The empty patches or even having Like there is currently this S&P kernel as Parallel a real-time kernel that could be used for monthly re-applications And I think that this was not that that no one uses monthly media because if you like code for like apropos I think you have this resource in the kernel that could be used for this kind of monthly re-applications and music So I just hope that this get under discussion to having kernel with real-time patches And I also like to have opinions about like Uh, so simply you want to know if we have separate versions of kernel with preempt and real-time support I know that we have preempt on right now in some kernels And we really shouldn't have been a lot of them My guess is that the virtual right now has a problem with the preempt But I don't really know if you guys have discussed it There It kind of relates to a discussion we've been having with each other Which is how can we reduce the number of flavors? Which is basically where The current thinking is the overhead of having S&P kernel running on a new processor Machine is probably negligible. It's not worth the effort This ties into your question because Essentially if real-time is working upstream, which I believe is currently not Every time I see a discussion of our own In this kernel mailing list There's several schools of thought don't want to agree with each other But if that was working and if it only presented a small overhead to set the web server I don't think there would be any problem with incorporating the Debian kernel But there's as I understand the status of code is just Not ready So in the future yes now Okay, I'm dreadfully sorry, but we can't take any more questions throughout the time But please feel free to come onto the kernel team and ask them Sure, they'll be happy to answer any questions you may have And thank you very much