Re: slowly decommission bugzilla?

----- Ursprüngliche Mail -----
> Von: "Thorsten Leemhuis" <[email protected]>
> Well, regular users reporting a bug usually don't deal with source files
> and might not even have an idea how to get from a module name to source
> files. For kernel developers it's obviously different, but those most
> likely have the source tree lying around already and thus can run
> scripts/get_maintainer.pl -f directly. So support for source files
> doesn't help that much, I'd say (but of course it would be "nice to
> have", too).
> 
>> module name,
> 
> This, on the other hand, would help quite a few people.
> 
> Also, broad categories with optional, more fine-graded subcategories
> would be nice for some areas. Like mm, which has 18 entries in
> MAINTAINERS that start with "MEMORY MANAGEMENT - ", which confuses
> people that do not know "if in doubt, just use the entry for MEMORY
> MANAGEMENT"
> 
>> heck even a stack trace or a BUG/WARN_ON/Oops
> 
> This even more (but of course this is harder)

Let's break down the problem a bit more.
What we want is a lookup mechanism where users can enter:
a) subsystem names,
b) source files,
c) module names,
d) kernel errors

to find a suitable mailing list to complain about.

With the MAINTAINERS file we have a lookup table which maps kernel source files to mailing lists,
that's already a good start.
That's good enough for a) and b).

Case c) lookup by module name is a bit tricky since the MAINTAINERS file does not really
know about modules.
What we could do is performing a allmodconfig build with CONFIG_DEBUG_INFO_DWARF5=y
and then extract the DRAWF compilation unit names from all *.ko files.
This gives us a module name to source file mapping.

Finally, and IMHO the most important input, are d) kernel errors.
Kernel errors we and users care mostly about have one thing in common: a stack trace.
stack traces are a list of symbols.
Extracting a stack trace from a random text (or log file) is not hard,
look for words of the from SYMNAME+0xNN/0xNN. Neither order nor duplicates
matter much.

What we need is a mapping between symbol names and source files.
That's also doable. e.g. by running "nm" on all *.ko files of a allmodconfig build.

So, from a given set of symbols we can find the matching module names and
mailing lists.

The very same approach will also work for core code. Beside of scanning *.ko
files, scanning built-in.a and even *.o files for non-module gives the same
results.

At the end we have a database (sqlite?) which can be fully automatically generated
from a kernel build and can be queried.
Nothing which can't be achieved with a few scripts.

>> and the interface gives an advice how to mail to which mailing list.
>> E.g. what information to include, how to send plain text mail, etc...
> 
> Yeah. But unless somebody volunteers to realize this within a few weeks,
> I'd say: Let's finally first reduce the immediate problem (users
> reporting bugs to a place where they might not even reach the
> developers) by putting a new welcome page on bugzilla.kernel.org in place.

Sure.

Thanks,
//richard