--DqhR8hV3EnoxUkKN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 03, 2006 at 06:50:27PM +0100, Liam J. Foy wrote:
> On 09:44, Mon 03 Apr 06, Bill Studenmund wrote:
> >=20
> > Huh? What you said touches on point (2) above, but not on any of the ot=
her=20
> > points. Sure, we can make it so we only incriment one counter, but that=
's=20
> > the easy part of all this.
>=20
> I was only touching on point (2) =3D)

Ok. :-)

> > The "magic" is that userland thinks there are multiple counters when th=
ere=20
> > aren't (I think it'd be a bad idea to make userland fetch a counter and=
 an=20
> > offset and have to do the subtraction).
>=20
> Why do you think this is a bad idea? I've been playing around and kinda
> implemented whats been discussed. I've two sets of counters, the
> original counters and another identical set. Right now 'netstat -Zp ip'
> will checkpoint the counters(IP) by copying the original counters, or 'ra=
w'
> counters, over to the checkpoint stats struct.

Because I think it's simpler and cleaner. Note: I'm assuming that both the=
=20
running and checkpointed counters are in the kernel. I think it's simpler=
=20
as we only export "running" and "since-checkpoint" counters, and the only=
=20
operation permitted by userland is to set the checkpoints to the current=20
values.

I'm not sure if I read you right, but I'd be very concerned about letting=
=20
userland load new "last-checkpoint" counters. "Set checkpoints to raw" is=
=20
very easy to audit and to log ("user X pid Y reset counters Z"). It's also=
=20
a simple operation to expose. "Load these checkpoint values" seems like a=
=20
much more abusable way to manipulate the counters. I think if an=20
administrator wants to play games like that, s/he should do it in=20
userland.

If the checkpointing were done totally in userland (kernel only knew about=
=20
raw counters), then obviously userland would have to deal with the math.=20
:-)

> You can then do 'netstat -szp ip' to few the difference since the
> checkpoint creation.
>=20
> I'm just using netstat for now, this can of course easily be changed.

I think what you're doing is fine for the command lines, however please
look at ifconfig too. Right now, -z will zero the counters in ifconfig. I
think it'd be bad if the command option to show since-zeroed counters in
one command was the same as the one to zero counters in another command.
:-|

> > But points (1) and (2) are the easy ones. They aren't why I think separ=
ate
> > counters are too much work for the benefit. That's in points (3), (4), =
and
> > the lack of scalability. :-)
>=20
> Not all programs need to know (as you said in point(3)). I don't see how
> point (3) is valid.

It's a matter of consistency. How many programs display stats in a=20
semi-interactive (or fully-interactive) manner? By that I mean not SNMP=20
consoles or things that only need "raw" counters and do magic themselves.

It could be that netstat and ifconfig are the only ones in base. But=20
systat may also need changing. But then supporting this feature becomes a=
=20
pkgsrc porting issue as well. :-(

It's also an issue of consistency. With not having checkpointing in the=20
kernel and only zeroing the "raw" counters, only the zeroing program needs=
=20
change. With the checkpointing you're describing, everything has to learn=
=20
about it.

And everything really should use a similar interface. Having '-z' zero for=
=20
some apps and report zeroed-based (checkpointed) counters in another is=20
bad. ifconfig -z has zeroed since NetBSD 2.0 (and actually for almost=20
exactly 3 years), so we'd need to proceed with caution if we want to=20
change it.

Take care,

Bill

--DqhR8hV3EnoxUkKN
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEMbXEWz+3JHUci9cRApTeAJ9tEFDfhNRaHCPIuS32geD4GaQzeACdHs4j
LWgaGqNCUtFtlbHvIamJ/B8=
=sjd7
-----END PGP SIGNATURE-----

--DqhR8hV3EnoxUkKN--