Re: bug database braindump from the kernel summit

[David Lang]

if we want to get the .config as part of the report then we need to make
it part of the kernel in some standard way (the old /proc/config flamewar)
it's difficult enough sometimes for the sysadmin of a box to know what
kernel is running on it, let alone a bug reporting script.

David Lang

 On Sun, 1 Apr
2001, Jeff Garzik wrote:

> Date: Sun, 1 Apr 2001 17:48:34 -0500 (CDT)
> From: Jeff Garzik <[e-mail]>
> To: Manfred Spraul <[e-mail]>
> Cc: Albert D. Cahalan <[e-mail]>, [e-mail],
>      [e-mail]
> Subject: Re: bug database braindump from the kernel summit
>
> On Sun, 1 Apr 2001, Manfred Spraul wrote:
> > From: "Jeff Garzik" <[e-mail]>
> > >
> > > /proc/pci data alone with every bug report is usually invaluable.
> >
> > Even if the bug is a compile error?
>
> In fact, yes.  Having the tuple of: .config, /proc/pci, and compile
> error output, you can see additionally if the user is doing something
> wrong.
>
> It allows you to fix the user as well as the compile error ;-)
>
>
> > E.g.
> > BUG REPORT (a real one, I didn't have the time yet to post a patch):
> > kernel versions: tested with 2.4.2-ac24, afaics 2.4.3 is also affected
> > Description:
> > Several config options are missing in the 'if' at the end of
> > linux/drivers/net/pcmcia/Config.in.
> > This means that CONFIG_PCMCIA_NETCARD is not set, and then (iirc) the
> > kernel won't link.
> >
> > CONFIG_ARCNET_COM20020_CS
> > CONFIG_PCMCIA_HERMES
> > CONFIG_AIRONET4500_CS
> > CONFIG_PCMCIA_IBMTR
> > are missing.
>
> noted.
>
> > Obviously too much data doesn't hurt, as long as
> > * it's hidden somewhere deep in a database, clearly separated from the
> > important parts (if there is an oops: decoded oops, description, how
> > easy is it to trigger the bug, steps to reproduce)
> > * very easy for the bug reporter to collect.
> > * not mandatory.
>
> agreed.
>
> Regards,
>
> 	Jeff
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>