Am 14.05.2014 19:53, schrieb Alexander Holler:
Am 14.05.2014 19:45, schrieb Alexander Holler:
One of the biggest problem of the deferred probe stuff is the problem
how to identify real problems if everything ends up with a deferred
probe when an error occurs? That means if you display an error whenever
something is deferred, the log becomes almost unreadable. If you don't
display an error, you never will see an error. And how do you display
the real error when deferred probes finally do fail? The deferred probe
stuff doesn't has any information about the underlying error, so it
can't display it.
And that is a real problem. I've recently tried to identify why a driver
failed and it was a nightmare because nothing offered any message (debug
or not) when a probe was deferred. So I had to insert tons of printks to
walk upwards to find the finally place where the probe failed.
Everything afterwards just has forwarded the -EPROBE_DEFER without
printing any message.
To add some numbers, I had to insert around 20-30 printks in around 10
or more files to find the underlying problem. Having to do such whenever
an error happens because everything assumes the error will disappear in
a later try, which doesn't happen for real errors, is just a nightmare.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
