> I also gave up on reporting kernel bugs.
I'm sorry to hear that. I know that reporting bugs is alot of work.
> Usually I am the only person with that bug and hardware
> configuration and nobody will fix it.
If no one else really has that HW, then there could be lots of reasons:
1) They don't care - many developers don't care about parisc, sparc, 100VG or tokenring
networking, scaling up or down (embedded vs large systems),e tc.
2) They don't have documentation for the offending HW.
3) no one else was able to reproduce the bug and it's not obvious what is wrong.
> This is not specific to the kernel though. I think I
> never got any of the bugs which I reported to fedora,
> red hat or gnome fixed.
Before someone else suggests these, maybe the way the bugs are reported has something to do
with the response rate?
There are some good essays/resources out there on how to file useful bugreports. I don't want
to suggest yours are not useful since I've never seen one (or don't know if I have). Just when
you mention problems across all open source projects I wonder.
> Two other things: is the kernel bugzilla used at all?
> are there any tests like unit tests to catch regressions for the kernel?
> both are pretty standard for any other open source project nowadays.
Agreed. But to be clear, the kernel is a bit different than most open source projects since it
controls HW and lots of buggy BIOS flavors.
(1) I'm using bugzilla.kernel.org to track tulip driver bugs. Not everyone is doing that. It's
helped that akpm has (had?) funding (from google?) for someone to help cleanup and poke
maintainers about outstanding bugs. Despite not everyone using it, it's still a better
tracking mechanism than sending an email to lkml. Do both. email to get attention and bugzilla
to track details. But also send bug reports to topic-specific lists since it's more likely
people who care about your HW will notice the report.
(2) Not that I'm aware of. The kernel interacts with HW alot. It's very difficult to emulate
or "mock" that interaction. Not impossible, just hard and the emulation almost never can
capture all the nuances of broken HW (see drivers/net/tg3.c for examples). Secondly, we very
often can only test large subsystems or several subsystems at once. e.g. a file system test
almost always ends up stressing the VM and IO subsystems. Networking stresses DMA and SK buff
allocators. UML and other virtualization of the OS make it possible to test some subsystems
w/o specific HW. However there are smaller pieces of the kernel which can be isolated and
tested: e.g bit ops (i.e. ffs()), resource allocators, etc. It's just a lot of work to
automate the testing of those bits of code. But this is certainly a good area to contribute if
someone wanted to learn how kernel code (doesn't? :)) work.
For testing subsystems, see autotest.kernel.org and http://ltp.sourceforge.net/. autotest is
attempting to find regressions during the development cycle.