On 16:54, Mon 03 Apr 06, Bill Studenmund wrote:
> On Mon, Apr 03, 2006 at 06:50:27PM +0100, Liam J. Foy wrote:
> > On 09:44, Mon 03 Apr 06, Bill Studenmund wrote:
> > > 
> > > Huh? What you said touches on point (2) above, but not on any of the other 
> > > points. Sure, we can make it so we only incriment one counter, but that's 
> > > the easy part of all this.
> > 
> > I was only touching on point (2) =)
> 
> Ok. :-)
> 
> > > The "magic" is that userland thinks there are multiple counters when there 
> > > aren't (I think it'd be a bad idea to make userland fetch a counter and an 
> > > offset and have to do the subtraction).
> > 
> > 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 'raw'
> > counters, over to the checkpoint stats struct.
> 
> Because I think it's simpler and cleaner. Note: I'm assuming that both the 
> running and checkpointed counters are in the kernel. I think it's simpler 
> as we only export "running" and "since-checkpoint" counters, and the only 
> operation permitted by userland is to set the checkpoints to the current 
> values.

I'm feeling pretty confused. You're right, both counters in the
implementation I have here are in the kernel. The current implementation
I have here copy for example, 'ipstats' into 'cp_ipstats' when a
checkpoint is requested through 'netstat -Zp ip' for example. 

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

Why concerned? I'm assuming by load you're meaning load the kernel
stats, for example 'cp_ipstats' into netstat for printing. However, the
current implementation I have here does nothing different to how the
'ipstats' is loaded in netstat. 'netstat -szp ip' I have here just reads
'cp_ipstats' instead of 'ipstats'.

I think we're confusing each other! :-)
 
> If the checkpointing were done totally in userland (kernel only knew about 
> raw counters), then obviously userland would have to deal with the math. 
> :-)
> 
> > You can then do 'netstat -szp ip' to few the difference since the
> > checkpoint creation.
> > 
> > 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.
> :-|

Sure, we can easily swap the options around in netstat =).

> 
> > > But points (1) and (2) are the easy ones. They aren't why I think separate
> > > counters are too much work for the benefit. That's in points (3), (4), and
> > > the lack of scalability. :-)
> > 
> > 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 
> semi-interactive (or fully-interactive) manner? By that I mean not SNMP 
> 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 
> systat may also need changing. But then supporting this feature becomes a 
> pkgsrc porting issue as well. :-(
> 
> It's also an issue of consistency. With not having checkpointing in the 
> kernel and only zeroing the "raw" counters, only the zeroing program needs 
> change. With the checkpointing you're describing, everything has to learn 
> about it.
> 
> And everything really should use a similar interface. Having '-z' zero for 
> some apps and report zeroed-based (checkpointed) counters in another is 
> bad. ifconfig -z has zeroed since NetBSD 2.0 (and actually for almost 
> exactly 3 years), so we'd need to proceed with caution if we want to 
> change it.


-- 
		Liam J. Foy
		<liamfoy@sepulcrum.org>
		http://www.bsdportal.org