| krocz | jaime date |
|---|---|
| Hackers. "Q&A about linux kernel. Closing Ceremony". Transtaltion #redes. | |
| Comentaries #qc' | |
| Hackers. "Q&A about linux kernel. Closing Ceremony". Translation #redes. | |
| Comentaries #qc' | |
| damage | los que ayudaran con la traduccion porfavor dirijanse a #redes |
| > jaime no logea ? | |
| krocz | jaime startlogs #linux |
| krocz | personas que ayudaran en la traduccion dirigirse a #redes y hablar |
| con damage | |
| riel | ok, I'd like to welcome you to the closing session of this year's Umeet |
| conference | |
| riel | this year we're doing a question & answer session on the kernel, |
| since it was very popular the last time we did one | |
| has joined #linux | |
| riel | but first, I'd like to thank a few people |
| riel | the Umeet organizers, who have been working hard to make these 2 |
| weeks of conferences possible | |
| riel | and the translators, who are translating most of the talks in #redes |
| riel | and today, of course, our panel members |
| riel | we got a number of kernel hackers who you can ask questions to in |
| the next hour or so | |
| riel | I'll try to introduce them in roughly alphabetical order |
| riel | Dave Jones - Fedora kernel maintainer, low level x86 hacker and |
| device driver hacker | |
| riel | Greg KH - device driver and device model hacker |
| riel | Marcelo Tosatti - 2.4 kernel maintainer |
| riel | Matthew Wilcox - developer of HPPA Linux, Debian developer and |
| many more things ;) | |
| riel | William Lee Irwin - memory management and scalability hacker |
| riel | and myself, but I'm mostly moderating the talk today ;) |
| riel | if you have any questions, please ask them in #qc |
| riel | then the kernel hackers will cut&paste your question here, and |
| answer them | |
| riel | heh, looks like we opened with a trick question ;( |
| riel | <trulux> davej, i've backported the selinux hooks for mount contexts |
| used in Fedora, what changes are needed outside the LSM/SE structure to make | |
| them working smoothly? | |
| davej | I don't really have enough background with selinux to provide an |
| answer on that one, sorry. | |
| riel | <voice=rusty> ok, any *OTHER* questions ? </voice> |
| davej | next? 8) |
| gregkh | rene> gregkh: what is your opinion of the current state of the |
| device model? anyspecific directions you | |
| riel | <rene> gregkh: what is your opinion of the current state of the device |
| model? anyspecific directions you want it to go which it isn't yet? | |
| gregkh | want it to go which it isn't yet? |
| gregkh | The current state is pretty good. It's stable, and works for almost |
| everyone. | |
| gregkh | that being said, there is some places that need work: |
| gregkh | - locking. The internal locking to the device model and sysfs |
| needs to be reworked in order for us to do more advanced things. I'll be working | |
| on that next month. | |
| #linux | |
| gregkh | - class support. We need to support children of class devices so |
| we can move /sys/block into /sys/class/ | |
| gregkh | - manual bind/ unbind of devices. We need to get the locking |
| changes finished so we can do this. | |
| gregkh | - make things simpler. It's still too hard in places to use the driver |
| model. We need more things like the class_simple type of interface. | |
| gregkh | - and finally, better documentation. But LDD3 will help solve that |
| one. | |
| reset by peer) | |
| riel | <mcr> I have been using User-Mode-Linux for nightly regression |
| testing of the KLIPS IPsec code. This has proven very effective. I would like to see | |
| more use of UML for regression testing of non-hardeware driver related items. | |
| Perhaps the assembled people could tell us what is keeping them from testing | |
| more extensively with UML. | |
| riel | I'll try to provide a short answer on my reasons ;) |
| riel | I am actually planning to use Xen virtualisation for testing |
| riel | and I have used User Mode Linux for debugging kernel code |
| riel | however, UML does behave differently from the real kernel in some |
| aspects, and it depends on the host kernel for strange corner case behaviour | |
| riel | it is also not very suitable for performance testing |
| riel | I know that cluster people and some network developers are using |
| UML for testing, though | |
| willy | <EricB> It seems that most vendors now ship their own kernel. Is this |
| becoming a problem or are the vendors being good about submitting patches for | |
| inclusion in linux? | |
| willy | Vendors have historically shipped their own kernels, and they used |
| to have | |
| willy | much more divergence from the upstream kernel than they currently |
| do. | |
| willy | The distribution vendors are better than before about submitting |
| patches | |
| willy | back to upstream. In particular, the hardware vendors are getting the |
| willy | message that they need to submit their code and APIs to the |
| upstream | |
| willy | kernel, not try to get the extensions into a distributor kernel first. |
| riel | as one of the distribution people, I've got another thing to add to this ;) |
| riel | two things, actually |
| riel | 1) Linux distributions have a QA team of maybe a few dozen people, |
| while the upstream kernel has a million users - so any change a distribution makes | |
| is less well tested than the upstream kernel, and a risk | |
| riel | 2) it is a lot of work to port patches from one kernel version to the next, |
| so for Linux distributions it actually saves work if their changes are sent to the | |
| upstream kernel first | |
| davej | from a fedora perspective, we're actually aiming at shipping less |
| patches with each release, and getting closer to that goal every time. | |
| davej | FC3 was around 40-50 patches away from mainline at time of |
| release, and many of those were post 2.6.9 backports fixing various things. | |
| davej | after release of FC3, the subsequent updates have increased the |
| patch count somewhat, but again, most of those are post 2.6.9 fixes taken from | |
| upstream. | |
| davej | the only bits that aren't, get pushed upstream so that when the |
| 2.6.10 based fedora kernel is rebased, we get to pick up those fixes for free. | |
| gregkh | And, as one of the Gentoo kernel maintainers, our kernel tree only |
| has 5 patches that are not upstream already. | |
| davej | impressive 8) |
| gregkh | and those patches are moving upstream soon. |
| gregkh | < damjan> gregkh: while on the device model, is power |
| management all right, but drivers implement it poorly or it needs work too? | |
| gregkh | power management is still under heavy design and development. |
| If you are interested in this, please join the new linux-pm mailing | |
| gregkh | list that is hosted by osdl. |
| riel | <trulux> riel, what's the opinion of the kernel hackers on NX |
| implementations and memory protection enhancements: Exec Shield, PaX.... etc? | |
| riel | ok, I've got a "non-standard" opinion on this question ;) |
| riel | I know that PaX protects against a few things that Exec-Shield does |
| not protect against as well | |
| riel | however, I think that the security conscious (aka paranoid) system |
| administrators are not the main target for these patches | |
| EOF from client) | |
| riel | the main goal of these patches is to protect systems that do not get all |
| security updates immediately | |
| riel | so I think the best of the two solutions is the one that can be enabled |
| without breaking any programs | |
| riel | so sysadmins will not have to disable the security mechanism |
| riel | Fedora already has execshield support, and I am happy to know that |
| other distributions (debian and gentoo) are also hardening their distribution | |
| gregkh | < roel> with the new development model, having a less |
| stable-on-all-times kernel, won't we depend even more on patched distribution | |
| kernels? | |
| gregkh | roel: you always depended on a "patched distribution" if you |
| wanted a stable kernel tree. | |
| gregkh | Now we just have finally acknolodged what we have been doing |
| for years. | |
| gregkh | that we have a relativly active kernel development cycle, and if you |
| want a tested and supported kernel, use a distro. | |
| gregkh | if you want the latest hardware support and bugfixes, use a distro |
| that tracks mainline quickly | |
| gregkh | (like Fedora, Debian and Gentoo.) |
| gregkh | if you want "stable, will never change in 5 years", then use an |
| "enterprise" distro, like RHEL or SLES. | |
| gregkh | you have options. |
| willy | I only use a patched distribution kernel on one of my machines; all |
| willy | the others (including my wife's) run kernels I've built myself. They're |
| willy | stable enough; her laptop is running 2.6.5 and has been up for 135 |
| days. | |
| com) has left #linux | |
| riel | <trulux> riel, also, is the FreeBSD jails port going to be integrated into |
| the kernel? | |
| riel | ok, this is one with many answers ;) |
| riel | first, Linux _does_ have a patch available that is like BSD jail, it is |
| called vserver | |
| riel | and people are using it in the same way |
| riel | selinux can also be used to restrict what programs can do, though |
| that requires more care | |
| riel | with proper tools, I think selinux configuration should also be |
| manageable | |
| riel | of course, in either case your system is still vulnerable to kernel |
| exploits | |
| riel | that leads us to the third answer to this question: virtualisation |
| riel | if you run untrusted services in their own virtual machine, with their |
| own kernel, then even a local kernel exploit could still leave the rest of the system | |
| safe (running on other virtual machines) | |
| willy | <weasel> Not a very technical question, but one regarding release |
| policy. Currently it often takes many weeks until known security problems get | |
| fixed not only in BK, but in a release. Do you intent to make use of x.y.z.N releases | |
| which fix such critical bugs quickly in the future, or at least make patches more | |
| widely known? | |
| willy | I agree with weasel that we don't do a very good job of fixing / |
| willy | announcing security bug fixes. I haven't heard either Linus or |
| Andrew | |
| willy | mention a desire to do security point releases; I suspect they're not |
| willy | interested in it themselves and assuming that if there is sufficient |
| willy | interest, someone will step forward to take care of it. |
| reset by peer) | |
| riel | distributions are taking care of it ;) |
| willy | well, distributions are taking care of it for their own kernels, but it'd |
| be nice if someone stepped up to manage security patches for the kernel.org | |
| kernels. | |
| davej | willy: which Alan has been doing to some degree in his -ac kernels. |
| davej | but I agree, a real .1 subrelease would be better |
| riel | ok, now for a good question, for which I do not have a good answer ... |
| riel | <ducky> what do you think about, whats the most strong barrier to the |
| enterprises to migrate all their servers to 2.6 | |
| davej | theres no 2.7 to backport cool 0day enterprise features from yet. |
| gregkh | fear, and people not wanting to change things that aren't broken :) |
| riel | I think one of the reasons is that 2.6 has not been tested well in a |
| production environment. There are few people on the linux-kernel mailing list who | |
| run a huge database on a 16 CPU system with 64GB memory - so who knows if it'll | |
| work right ? | |
| willy | possibly they're using some really old device driver that doesn't |
| work in 2.6 yet | |
| has left #linux | |
| willy | <EricB> Is there going to be any effort made to split up the source by |
| arch? Most people only need one or two | |
| willy | No, we're not keen on pruning / trimming the source tree. While it |
| willy | would make life easier for people who download the kernel tarball, |
| it'd | |
| willy | be much more load on the mirrors and on developers. The .diff files |
| willy | aren't awfully big, so you only need to download one copy of the |
| tarball. | |
| marcelo | <ducky> what about your experiences as a the 2.4 linux kernel |
| maintainer ? | |
| marcelo | I have learned a lot during these years, about relationship with |
| other developers/members | |
| marcelo | of the community and also about technical matters. I've came to |
| know and interact with a large | |
| marcelo | number of developers. |
| marcelo | Maintenance of a stable Linux kernel tree is a big responsability, |
| and its a long-term | |
| marcelo | commitment. It has occupied most of my time for during these |
| years. | |
| marcelo | Its not an easy task - one feels responsible for all bugs which |
| might appear, that can | |
| marcelo | be very frustating at times. |
| marcelo | s/my time for/my time/ |
| marcelo | But in the end it has been a wonderful personal experience, I |
| have learned a lot from it | |
| marcelo | and continue doing so. |
| willy | mcr solicited opinions from people other than riel on use of UML. |
| Most of my kernel changes are hardware related, so booting a UML kernel | |
| wouldn't help test my changes. For people like network developers and perhaps | |
| VM hackers, UML is great, but when you need to alter device driver or PCI bus | |
| walking code, it's not much good. Also, a lot of the time I work on stuff that is | |
| ia64-specific, and I don't think there's UML for ia64 yet. | |
| gregkh | < mb_> What about the BKL. Can we expect that there will be the |
| day when it disappears? Is work going on there? | |
| gregkh | There is a bit of bkl work going on in trying to get rid of it in the |
| ioctl calls, but | |
| gregkh | the main "get rid of the bkl" work is over. The developers who |
| worked on it are off doing other things now, and | |
| gregkh | unless there is some measured benifits from dropping it in the rest |
| of the kernel, I doubt it will ever go away completly. | |
| willy | There are still large parts of the kernel that use the BKL, but they're |
| almost all infrequently called paths. Contention on the BKL is very low these | |
| days; there are many more interesting problems to attack in terms of scalability. | |
| riel | <warren> Q: Are we still plagued by VM balancing problems? Will |
| there ever be an end to it? | |
| riel | the VM has the big problem that nobody agrees on exactly what it |
| should do, so it's not possible to create a test set that ensures it does the right | |
| thing ;) | |
| riel | for that reason, I suspect we will have VM balancing problems for a |
| while more | |
| riel | also, the VM has a tendency to break when you optimise it too much, |
| so if you optimise for one benchmark, you probably make performance worse for | |
| something else | |
| riel | this is a fundamental problem, because the VM has to swap |
| _something_ out when memory is low | |
| riel | and there is always some program that will use that memory again in |
| the future | |
| riel | the task of the VM is to swap out the page that makes the VM suck the |
| least ;) | |
| gregkh | < rene> while on the topic. where _is_ early userspace? :) |
| gregkh | The "early userspace" code is already in the 2.6 kernel today. |
| Look at | |
| gregkh | the initramfs code, there is documentation on how to use it in the |
| gregkh | Documentation/ directory. People are still working on merging in |
| gregkh | the klibc code into the kernel tree, when that is done, then we can |
| begin | |
| gregkh | to pull pieces of the kernel boot process logic out of kernelspace |
| gregkh | and into userspace, yet having them remain as part of the kernel |
| gregkh | build process. For more info on this, see the klibc mailing list |
| gregkh | archives. |
| willy | <tklauser> How do driver developers and lowlevel hackers test their |
| code? Isn't it difficult to debug code at such a low level? | |
| willy | I think people believe there's some kind of mystique to kernel |
| hacking. | |
| willy | There isn't really. It's just that when you write bad code, the entire |
| willy | machine crashes, not just the program you were writing. So we test |
| our | |
| willy | code in much the same way that other hackers do. Everyone's |
| different; I | |
| willy | tend to write code, compile it, fix compile problems, boot it (usually |
| on | |
| willy | a different machine ;-), fix boot problems, stress it, fix those |
| problems. | |
| willy | Once I can't break it any more, I send it out for other people to try |
| willy | to break it. They usually do ... |
| riel | <krocz> riel: how hard would it be to run grsecurity with xen? |
| riel | well, every Xen guest runs its own kernel |
| riel | so it should be relatively easy to run grsecurity on such a kernel |
| riel | the only parts that may need porting are the architecture specific |
| ones, but those should be few | |
| willy | <damjan> What's the general feeling amongst the main kernel |
| hackers about user-space filesystems (like FUSE), will it go in mainline? Also what | |
| about per-user (or per process) VFS namespaces ... Also what about overlay | |
| mounts? | |
| willy | The FUSE guy seems really interested in getting his code merged. |
| willy | Linus found some problems with it, but I think they're fixed now. |
| willy | If he's persistent, continues to fix bugs and doesn't get irritating, |
| willy | that code may be integrated fairly soon. |
| willy | Per process VFS namespaces are already implemented. I think |
| overlay | |
| willy | mounts can be done most easily by writing a new filesystem (I believe |
| willy | this is how BSD implements it). So it's easy enough, just write a |
| willy | new filesystem! |
| riel | <krocz> what parts of the linux kernel does Xen patch? |
| riel | Xen is a new pseudo-architecture, like User Mode Linux |
| riel | so it patches arch/xen/ and adds some Xen specific virtual device |
| drivers | |
| riel | it reuses large parts of arch/i386/ to avoid code duplication |
| riel | and touches a little bit of code elsewhere |
| riel | <warren> Q: On the topic of filesystems, what will it take to enable use |
| of mount --bind -o ro to have a filesystem read-only in one location, read-write in | |
| another simultaneously? Existing patches (from vserver authors) against 2.6 were | |
| rejected a few months ago. Any further work in this direction? | |
| riel | I am not aware of further work here, though the vserver people may be |
| working on it still. | |
| willy | <damjan> I also have a question about improving robustness of the |
| kernel, if you got processes stucked somewhere in the kernel (waiting on NFS, | |
| CIFS or bad CD) the only thing you can do is a restart ... can something be done | |
| about it? | |
| willy | Actually, Linus posted an outline of a way to handle this a few years |
| ago. | |
| willy | http://seclists.org/lists/linux-kernel/2002/Aug/0467.html |
| willy | Nobody's implemented it yet; you could be the one to do it ;-) |
| riel | ok, it looks like we are out of questions (and out of time) now |
| riel | thanks to everybody for being at this year's Umeet conference |
| riel | I'll hand over the virtual microphone to MJesus, who coordinates |
| Uninet ;) | |
| willy | I'd like to thank Rik for his efforts in herding cats (aka organising |
| kernel hackers) | |
| riel | I would like to thank all the speakers, panel members, conference |
| organisers, translaters ... | |
| riel | ... and of course, the audience |
| riel | thank you |
| exiting) | |
| krocz | CLAP CLAP CLAP CLAP |
| krocz | CLAP CLAP CLAP CLAP |
| krocz | CLAP CLAP CLAP CLAP |
| krocz | CLAP CLAP CLAP CLAP |
| fernand0 | plas plas plas plas plas plas plas plas plas plas plas plas |
| fernand0 | plas plas plas plas plas plas plas plas plas plas plas plas |
| fernand0 | plas plas plas plas plas plas plas plas plas plas plas plas |
| fernand0 | plas plas plas plas plas plas plas plas plas plas plas plas |
| fernand0 | plas plas plas plas plas plas plas plas plas plas plas plas |
| fernand0 | plas plas plas plas plas plas plas plas plas plas plas plas |
| damage | CLAP CLAP CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| damage | CLAP CLAP CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| damage | CLAP CLAP CLAP CLAP CLAP CLAP CLAP CLAP CLAP |
| ^ogro^ | bravo!!!!!!! |
| jaime | ^ogro^: Aviso #1 => Agradeceria mucho que no escribieras !!!!!!! otra |
| vez | |
| fernand0 | plas plas plas plas plas plas plas plas plas plas plas plas |
| ducky | clap clap clap clap clap clap clap clap |
| fernand0 | plas plas plas plas plas plas plas plas plas plas plas plas |
| fernand0 | plas plas plas plas plas plas plas plas plas plas plas plas |
| ducky | clap clap clap clap clap clap clap clap |
| ducky | clap clap clap clap clap clap clap clap |
| ducky | clap clap clap clap clap clap clap clap |
| ducky | clap clap clap clap clap clap clap clap |
| krocz | jaiem endlog #linux |
| jjose | PLAS PLAS PLAS |
| #linux | |
| krocz | jaime endlog #linux |
| jaime | krocz: Log cerrado! |
| krocz | thanks to riel and all kernel hacker |
| roel | indeed, thanks |
| > clap clap clap clap clap clap clap clap clap clap | |
| > clap clap clap clap clap clap clap clap clap clap | |
| > clap clap clap clap clap clap clap clap clap clap | |
| > clap clap clap clap clap clap clap clap clap clap | |
| > clap clap clap clap clap clap clap clap clap clap | |
| > clap clap clap clap clap clap clap clap clap clap | |
| > clap clap clap clap clap clap clap clap clap clap | |
| > traslator are still reading :)) | |
The Organizing Comittee
