On Sun, May 25, 2008 at 10:44:52PM +0200, Davi Leal wrote:
This is precisely one of our big problems right now. Software is almost
only tested by authors, which means that we accumulate a lot of bugs due
to lack of precise knowledge in every area. Locking bugs and lack of
pointer validation come to mind.
Rafael Wysocki regularly sends a compiled list of known regressions. A
lot of them require specific hardware to trigger a driver bug, but there
are others with reproducers (and BTW you might also have some of the
required hardware).
Arjan van de Ven has posted a list of the top 10 oopses (check
www.kerneloops.org). It's not always easy to trigger such bugs,
but you may find it interesting to read the functions spotted in
the stack traces and try to understand how they work together.
As Linus often says : "read the sources". Reading the code of all of a
call chain between a syscall and an oops can be *very* instructive. You
need serious motivation though. At first you will think that you don't
understand a damn thing. That's normal and expected. It does it to me
each time I stuff my nose in a file. You just need not to suppose what
a function or macro does, but to read it. You'll quickly understand what
the code does, and very likely both find stupid bugs and understand the
kernel internals.
reading code is 100% compatible with time constraints, as there is no
deadline. You can even say that a bug that you don't look at may stay
there for years. And quite frankly, spending more than one hour every
evening on code is generally enough to give you a headache. But you
will progress very quickly.
That's a good idea, though I have no clue how to proceed.
Please check the list for Arjan and Rafael's posts. Take something which
seems close to an area you would like to progress in. Maybe you're more
interested in writing drivers, file-systems, schedulers, VM, etc...
Regards,
Willy
--
