Peter Memishian wrote:
> I'd like to draft a proposal to EOF/eliminate the handling of persistent > kstats. IMO, a kstat should be cleaned up once kstat_destroy() is > called, unconditionally. (The definition of KSTAT_FLAG_PERSISTENT > should be left alone, with admonishments against its use.) This does > mean that update_drv and driver detaches will result in loss of > historical information.

The notion of all such data being "historical" seems a bit odd.  In
particular, especially on DEBUG systems, the administrator may not be
aware of when attach and detach operations are occurring.  So the result
will be that kstats for occasionally-needed kernel modules will be
constantly getting cleared.  That doesn't seem good to me.

Huh. I'm not sure how the administrator doesn't know about attach/detach operations. Am I missing something? I thought DR was pretty much administrator driven.

However, I could see an argument for having update_drv firing off an ioctl
to torch persistent kstats so that the updated driver can reliably
reattach.

That might be a reasonable alternative.

   -- Garrett

_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to