[snip]
> > Problem details
> > Bug report quality
> > There was lots of discussion on this. The main agreement was that we
> > wanted the bug reporting system to dig out as much info as possible
> > and prefill that. There was a lot of discussion about possible tools
> > that would dig out the /proc/pci info; there was discussion about
> > Andre's tools which can tell you if you can write your disk; someone
> > else had something similar.
>
> This is controversial, due to the potential for unwanted information
> disclosure. I purposely didn't implement it. If a large proportion
> of users want it implemented, just let me know.
Having said that, I've had a .config uploading and analysing facility
since version 1.0. Infact, the reason I forgot to mention it in my
first E-Mail, is that it is the core around which the whole Kernel Bug
Database operates. The user uploads their .config, and the database
finds bugs that might be the one you're experiencing. If so, you add
a separate bug report, an admin collects both bug reports in to one
confirmed bug, and picks out which config options he wants to flag as
causing the confirmed bug.
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/