Linked by Rahul on Thu 20th Nov 2008 04:31 UTC
Arjan van de Ven from Intel Open source centre has posted the news that http://kerneloops.org has recorded its 100,000 oops. An oops in the Linux kernel is a deviation from correct behavior of the Linux kernel which produces a certain error log. kerneloops is a client side software that helps record oops more automatically on the website with the same name and is available as part of many distribution repositories and even included by default in Fedora. This is part of the QA efforts in the Linux kernel and when posting the news, Arjan has noted that Linux kernel developers have been fixes most of the top oopses quickly
Thread beginning with comment 337834
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-11-10
Is that unexpected when you have binary code targetting a constantly changing interface?
The problem is not the changing interface, but the lack of peer review. That's why Free Software drivers don't oops the kernel so much and they also have to deal with changing interfaces.
Member since:2005-12-02
"The problem is not the changing interface, but the lack of peer review. That's why Free Software drivers don't oops the kernel so much and they also have to deal with changing interfaces."
The interface does change. The peer review helps, however the people writing the majority of the drivers for Linux are kernel developers, so would be aware of the changes. That is actually why free software drivers do not oops the kernel as much as binary. Please correct me if I am wrong, as I very well could be not being involved in kernel development at all.
Member since:2005-07-07
Member since:2006-07-15
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2005-07-07
Interesting is that most of the oopses seem to come from binary-only parts (external blob drivers)
Is that unexpected when you have binary code targetting a constantly changing interface?