Hmm... okay, I understand that some believe we may need kstats to
outlast a ddi-detach.
Although I'm not 100% convinced on that matter. I still believe that
any device for which you're collecting kstats that are interesting to
admins is probably either a disk or a nic, and generally those are only
interesting to admins if they are in use and thus not eligible for
detach by modunload -i 0.
I guess if you had a lot of mount/umount activity on a filesystem, or
plumb/unplumb. But that usage seems highly atypical to me.
Certainly I'm finding it hard to find any good counter-examples.
Additionally, I believe reporting of statistics for devices that are
_not_ in the system at the time is more likely to cause confusion.
(Remember, modunload -i 0 isn't the only reason the device is gone... it
could be gone because it was physically removed!)
In any case, I think an ioctl from update_drv is not sufficent.... we
need a way to clear the kstat unconditionally. Is update_drv *always*
executed when updating a driver? I'm not sure, in part because I don't
know how patches are delivered these days. And update_drv might not be
able to clear the kstat at that time anyway, because it might not be
able to unload the driver (e.g. the NIC is in use at patchadd time, but
a little while later it is unplumbed, and the new driver is reloaded.)
Far, far better to have some automated way to deal with this at device
driver attach time, IMO. Some kind of KSTAT_OVERWRITE_INCOMPATIBLE
kstat or somesuch. (Of course in this situation you are clearing old
kstats, which now creates another inconsistent behavior.)
I'm a big, big fan of consistency.
In my opinion, clearing the kstats when a driver unloads (because it
isn't in use!) is consistent. I don't think administrators are likely
to expect that a kstat would outlive a device drivers attachment in the
kernel. And the fact that if the driver is unloaded after the nic is
unplumbed, that the stats go by by, really shouldn't be a big deal.
Note also that there is a crtime value for kstats which administrators
or tools can use to help them detect when this situation has occurred.
(Although admittedly it would be nice if kstat(1M) could display
crtime() and snaptime() in human readable form.)
-- Garrett
Peter Memishian wrote:
> Generally, all devices that are "interesting" are likely to have some
> upper layer plumbed on them. Networking devices have IP. Disks have
> filesystems, etc.
I agree, but I still find it confusing to couple the resetting of kstats
with events that cannot necessarily be administratively predicted or
easily observed. Your original problem statement centered around the
update_drv case, for which the intended administrative semantics seem much
more clear-cut. Hence my suggestion to destroy the persistent kstats in
that case.
> If the device isn't in use, then probably the historical data simply is
> not interesting.
Personally, I'm not swayed by that argument. Solaris is inherently
dynamic; assuming that collected data for a particular device is no longer
interesting just because the device is not currently being used seems
flawed. (I'm certainly not in love with KSTAT_FLAG_PERSISTENT, but I do
think it serves a purpose of ensuring that data is not lost unexpectedly.)
Perhaps others feel differently.
> Also, the use of KSTAT_FLAG_PERSISTENT is itself, very inconsistent
> among device drivers.
OK, but that's a separate matter -- the original argument here was that
KSTAT_FLAG_PERSISTENT is inherently flawed, not that it's merely applied
inconsistently.
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
