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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
