From owner-freebsd-hackers Sun Dec 24 17:36:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA20779 for hackers-outgoing; Sun, 24 Dec 1995 17:36:42 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA20774 for ; Sun, 24 Dec 1995 17:36:37 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id MAA13380; Mon, 25 Dec 1995 12:33:27 +1100 Date: Mon, 25 Dec 1995 12:33:27 +1100 From: Bruce Evans Message-Id: <199512250133.MAA13380@godzilla.zeta.org.au> To: Mattias.Gronlund@sa.erisoft.se, bde@zeta.org.au Subject: Re: iostat and msps Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >OK, if we can't calculate msps on new disk's, what is the reason for >it to still exist? They can be calculated accurately for some disks (for floppies and old uncached wd drives :-) and inaccurately for other cases. >> Lots of things would break even if DK_NDRIVE only increased. systat >> output wouldn't fit in 80 columns... >So, I have checked, the only system binaries that uses the dk_xxx >variables from /dev/kmem is systat and iostat and I guess that it >should be possible to fix them if they break :-)... I think Joe Greco fixed some things here. >But if one should create a dynamic implementation of the dk_xxx >statistics ( What do dk stand for? ) whouldn't it be better to >use sysctl then /dev/kmem? sysctl then sysctl. >Is it possible that an dynamic implementation of thous statistics could >be intergrated into FreeBSD-current? Someone has to do the work. It would be nice if every driver didn't have to know how to manage the statistics. They could call (inline) functions but the placement of the calls is driver-dependent. Bruce