Gavin Maltby wrote:
On 05/03/07 20:04, Garrett D'Amore wrote:
If the device isn't in use, then probably the historical data simply
is not interesting.
They could be useful in post-mortem debugging where they represent
a small handle on past history relative to the snapshot-in-time
which the system crash dump represents.
Hmm... I think that's a pretty narrow "could". In the vast majority of
cases, drivers that have interesting kstats don't come and go very
often, and when they do, it is usually due to DR. Dynamic
Reconfiguration is such a massive impact on the system that I doubt very
much that data from _before_ the DR operation is likely to be useful in
debugging an event that occurred _after_ the DR, with the possible
exception of debugging the DR event itself. (But in that case,
generally the problem is with a device that refuses to detach, and
therefore won't have destroyed its stats!)
So I'd suggest the solution is not to eliminate persistent kstats
from the OS entirely, but instead to find a simple mechanism to
detect when they are acting obstructively (as in the case you
describe) rather than as a history mechanism, and to cleanup
in those case or allow the driver some means to force the cleanup.
This is a potential solution. The only thing I don't like about this is
the heuristic value... does the kstat represent useful information from
before, or after the DR? Its hard to know unless you pay attention to
the crtime.
I wonder, one solution could be to copy the kstat to some kind of
"historical" stats section, if the persistent flag is in use.
In any case, rather than a conditional "clobber the kstat if it appears
different" (which right now is a stupid heuristic based on size), I'd
like to see the kstat clobbered when a driver reattaches.
-- Garrett
Gavin
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
