Linux kernel 'getting buggier'[英文](轉)
Linux kernel 'getting buggier'[英文](轉)[@more@]Ingrid Marson
ZDNet UK
May 05, 2006, 16:35 BST
Linux kernel maintainer Andrew Morton may force developers to devote one kernel cycle to fix long-standing bugs in the Linux kernel
Andrew Morton, the lead maintainer of the Linux production kernel, is worried that an increasing number of defects are appearing in the 2.6 kernel and is considering drastic action to resolve it.
"I believe the 2.6 kernel is slowly getting buggier. It seems we're adding bugs at a higher rate than we're fixing them," Morton said, in a talk at the LinuxTag conference in Wiesbaden, Germany, on Friday.
Morton admitted he hasn't yet proved this statistically, but has noticed that he is getting more emails with bug reports. If he is able to confirm the increasing defect rate, he may temporarily halt the kernel development process to spend time resolving bugs.
"A little action item I've given myself is to confirm that this increasing defect rate is really happening. If it is, we need to do something about it." he said. "Kernel developers will need to reapportion their time and spend more time fixing bugs. We may possibly have a bug-fix only kernel cycle, which is purely for fixing up long-standing bugs."
One problem is that few developers are motivated to work on bugs, according to Morton. This is particularly a problem for bugs that affect old computers or peripherals, as kernel developers working for corporations don't tend to care about out-of-date hardware, he said. Nowadays, many kernel developers are employed by IT companies, such as hardware manufacturers, which can cause problems as they can mainly be motivated by self-interest.
"If you're a company that employs a kernel maintainer, you don't have an interest in working on a five-year-old peripheral that no one is selling any more. I can understand that, but it is a problem as people are still using that hardware. The presence of that bug affects the whole kernel process, and can hold up the kernel — as there are bugs, but no one is fixing them," said Morton.
During his talk, Morton discussed the 2.6 kernel development process, explaining that if people want to get their code into the kernel they should send it to him, not Linus Torvalds, who maintains the development kernel. Morton manages the "-mm" code branch, which is where patches are tested before being added to the development kernel.
"The way an individual can get their code into the kernel is by sending it to me. I will buffer it in my [mm] tree and send it to Linus. It's fairly rare for a person to send patch to Linus and get it in. In fact Linus is fairly random at patches at the best of times. Generally, Linus will cc: it to me because he knows I'll pick it up," said Morton.
"The mm tree is what Linus' tree is going to look like in three months time. A lot of stupid bugs get in. I wish people would send me code that compiles — probably about 75 percent do," he said. "Without mm all of these problems wouldn't be discovered until hit they hit the mainline tree and would impact everyone's ongoing development."
The LinuxTag conference goes on until Saturday. Talks that take place in the main conference room can be watched online via a free Webcast (instructions in German).
ZDNet UK
May 05, 2006, 16:35 BST
Linux kernel maintainer Andrew Morton may force developers to devote one kernel cycle to fix long-standing bugs in the Linux kernel
Andrew Morton, the lead maintainer of the Linux production kernel, is worried that an increasing number of defects are appearing in the 2.6 kernel and is considering drastic action to resolve it.
"I believe the 2.6 kernel is slowly getting buggier. It seems we're adding bugs at a higher rate than we're fixing them," Morton said, in a talk at the LinuxTag conference in Wiesbaden, Germany, on Friday.
Morton admitted he hasn't yet proved this statistically, but has noticed that he is getting more emails with bug reports. If he is able to confirm the increasing defect rate, he may temporarily halt the kernel development process to spend time resolving bugs.
"A little action item I've given myself is to confirm that this increasing defect rate is really happening. If it is, we need to do something about it." he said. "Kernel developers will need to reapportion their time and spend more time fixing bugs. We may possibly have a bug-fix only kernel cycle, which is purely for fixing up long-standing bugs."
One problem is that few developers are motivated to work on bugs, according to Morton. This is particularly a problem for bugs that affect old computers or peripherals, as kernel developers working for corporations don't tend to care about out-of-date hardware, he said. Nowadays, many kernel developers are employed by IT companies, such as hardware manufacturers, which can cause problems as they can mainly be motivated by self-interest.
"If you're a company that employs a kernel maintainer, you don't have an interest in working on a five-year-old peripheral that no one is selling any more. I can understand that, but it is a problem as people are still using that hardware. The presence of that bug affects the whole kernel process, and can hold up the kernel — as there are bugs, but no one is fixing them," said Morton.
During his talk, Morton discussed the 2.6 kernel development process, explaining that if people want to get their code into the kernel they should send it to him, not Linus Torvalds, who maintains the development kernel. Morton manages the "-mm" code branch, which is where patches are tested before being added to the development kernel.
"The way an individual can get their code into the kernel is by sending it to me. I will buffer it in my [mm] tree and send it to Linus. It's fairly rare for a person to send patch to Linus and get it in. In fact Linus is fairly random at patches at the best of times. Generally, Linus will cc: it to me because he knows I'll pick it up," said Morton.
"The mm tree is what Linus' tree is going to look like in three months time. A lot of stupid bugs get in. I wish people would send me code that compiles — probably about 75 percent do," he said. "Without mm all of these problems wouldn't be discovered until hit they hit the mainline tree and would impact everyone's ongoing development."
The LinuxTag conference goes on until Saturday. Talks that take place in the main conference room can be watched online via a free Webcast (instructions in German).
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10617542/viewspace-958458/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- linux kernel 2.6.11.12(轉)Linux
- Linux Kernel V2.6.15.5(轉)Linux
- Linux Kernel ACL訪問控制漏洞(轉)Linux
- Getting Listeners from JavaBeansTM (轉)JavaBean
- Linux kernel mapLinux
- Linux Kernel(核)Linux
- Linux Kernel 2.6 核心執行緒嚐鮮(轉)Linux執行緒
- 在Linux Kernel內新增一個System Call(轉)Linux
- 著名美國電信公司招聘linux kernel engineer(轉)Linux
- Getting Testing PKGBUILDs(轉)UI
- 對話#25:Getting to the Point (轉)
- [轉]Hugemem Kernel ExplainedAI
- Hugemem Kernel Explained [轉]AI
- Linux kernel 2.6.32.30Linux
- 複製RedHat Linux系統(轉貼,,中英文)(轉)RedhatLinux
- Linux Kernel File IO Syscall Kernel-Source-Code Analysis(undone)Linux
- Linux Kernel2.6x 最新本地溢位程式碼(轉)Linux
- [Linux] kernel: page allocation failureLinuxAI
- Linux kernel engineer--traceLinux
- Memory Allocation API In Linux Kernel && Linux Userspace、kmalloc vmalloc Difference、Kernel Large Section Memory AllocationAPILinux
- iptables新增模組(for kernel 2.6)(轉)
- Python 英文的月份轉數字及數字轉英文Python
- Unable to Find Sources for Current Linux KernelLinux
- Linux Boot,Kernel 和 Service 介紹Linuxboot
- Linux動態列印kernel日誌Linux
- Linux Kernel 3.10 正式釋出Linux
- Linux Kernel 3.0.50/3.2.33/3.4.17/3.6.5Linux
- Linux Kernel 3.8.8/3.4.41/3.0.74 釋出Linux
- Linux Kernel 3.4.8/3.2.27/3.0.40 釋出Linux
- Linux kernel 堆溢位利用方法Linux
- Structure of Linux Kernel Device Driver(Part II)StructLinuxdev
- Linux核心Kernel啟動過程Linux
- 檢視linux的版本號(非linux kernel)Linux
- Linux的英文發音&未來軟體界的方向(轉)Linux
- bootsplash for slackware kernel-2.6.12!(轉)boot
- kernel hacking簡單入門(轉)
- 英文大小寫轉換
- [轉]符號的英文叫法符號