On 09:44, Mon 03 Apr 06, Bill Studenmund wrote:
> On Sat, Apr 01, 2006 at 11:18:30AM +0100, Liam J. Foy wrote:
> > On 23:24, Fri 31 Mar 06, Bill Studenmund wrote:
> > > On Fri, Mar 31, 2006 at 10:54:34PM +0200, Havard Eidnes wrote:
> > > My concern with "checkpointing", as it's described so far, is that it
> > > really only permits you one level of checkpointing, for a lot of work.  
> > > We: 1) double the number of counters, 2) incriment these extra counters
> > > (ok, this isn't so bad, and could be adjusted with some implementation
> > > magic so that you only incriment one counter), 3) teach almost all
> > > counter-using programs about these new counters, and 4) teach
> > > administrators about all these new counters. And we only get one
> > > checkpoint.
> > 
> > Well, you wouldn't really be incrementing these other counters at all,
> > merely copying them so no magic implementation would really be needed
> > from how I see it.
> 
> 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) =)
 
> 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.

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.

> 
> 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.

> 
> Take care,
> 
> Bill

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