Re: Dedicated kernel bug database

[Stephen Wille Padnos]

Hmmm.

It seems to me that a kernel bug tracking system has to have a pretty 
good knowledge (database) of  the kernel(s) it is meant to track. 
 Essentially, a user who has a problem can usually identify what the 
problem is ("my external firewire HD doesn't work"), but not where the 
cause may be (interrupts / filesystem drivers / mount tools / scsi 
generic / sbp2 / ieee1394 / pci / ACPI / APIC / VM / ...).

So, if a user could enter some keywords for their problem and get a list 
of possible subsystems that it depends on (along with maintainers for 
those subsystems), we'd be getting somewhere.

For the usb / apic / acpi / rtl8139 problem, I would enter something 
like USB keyboard, 8139too, local APIC, IO-APIC, VIA kt333, kernel 2.5.45-51

The wizardly database (knowing what each "leaf device" depends on), then 
finds the intersection of  subsystems that affect all (or some specified 
percentage) of the things the keywords match.

This requires a tree of dependencies (pretty much there - look at what 
headers are included in each source file) for each driver.

Of course, there are things that everything depends on (VM), which would 
probably want to be left out unless no higher level common ancestor of 
the problems can be found.

The trouble with searching a flat bug database is that you have to know 
what you're looking for.  If the bug tracker actually helped figure out 
the problem (where possible, of course), that would be a boon.

John Bradford wrote:

[snip snip]

>>| Overall, though, would you rather be presented with a list of
>>| categories, or a list of people and what parts of the code they
>>| maintain.  Personally, I think that a list of people is more
>>| intuitive, rather than an abstract list of categories, but I could be
>>| wrong.
>>
>>Do we have anyone targeted for interrupt routing problems (PIC, IO APIC,
>>ACPI, etc.)?
>>    
>>
>
>No.  I nominate Alan :-).
>
Agreed.  (can he be elected without knowing he's on the ballot? :)