Messages in this thread | | | Date | Sun, 9 Jul 2006 14:46:28 -0400 | From | "Daniel Bonekeeper" <> | Subject | Re: Automatic Kernel Bug Report |
| |
> I'm sorry for being so negative, but it seems you are overdesigning a > solution for a non-existing problem: > > There are cases where the machine is simply dead with exactly zero > information. These are the really hard ones. >
Then really there isn't anything that we can do, except to expect the kindness of the user in taking a picture of his screen and posting on the kernel's bugzilla.
> Then there are cases where the kernel is able to print a BUG() or Oops > to a log file. Or the error message is printed to the screen and the > user uses a digital camera and sends the photo.
Then again, users may just continue using the machine (without even noticing the Oops), or notice but never care to report it, or forgets, etc.
> The message is usually enough for starting to debug the problem or > asking the user for additional information. > > But most important, the problem lies in a completely different area: > > Interaction between kernel devlopers and users is not a real problem. > The real problem is the missing developer manpower for handling bug > reports. >
Well Adrian, this is the other side of the problem. We don't actually need a kernel monkey to keep looking for bugs that comes (even thought would be good, but as you stated, there is not enough manpower to do that), even more after having something that automatically sends Oops reports to the server, where we could expect thousands of bug reports daily... but I also believe that not having somebody to look at them is not an excuse for not having this bug taken account for. For example, even though we may not debug each and every bug report, we can have statistics for which modules are reporting more problems (and therefore, have more bugs). For example, I don't really expect Microsoft to investigate every crash report that users send, but it is definitely important to have bugs accounted for. Let's say that the SCSI maintainer just did a big change to the SCSI subsystem and wants to know how is it going: he just goes to bugzilla and see statistics about increase of the ratio of bug reports compared to the last version, or he can also see which functions (based on the EIP as a guess) are reporting more problems.
In resume, don't being able to investigate each report isn't a reason for not being acknowledged of its existance, and even we don't investigate it, having it for statistical purposes is already a great deal.
Daniel
-- What this world needs is a good five-dollar plasma weapon. - 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/
| |