pcp
[Top] [All Lists]

Re: [RFC] possible pcp atop rework

To: Stan Cox <scox@xxxxxxxxxx>
Subject: Re: [RFC] possible pcp atop rework
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Thu, 26 Mar 2015 18:09:58 -0400 (EDT)
Cc: PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <55146389.9070801@xxxxxxxxxx>
References: <374510893.3368065.1427153308075.JavaMail.zimbra@xxxxxxxxxx> <2015628916.3378820.1427154140867.JavaMail.zimbra@xxxxxxxxxx> <55146389.9070801@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: Jys0rNL6NLQwPY54UG9N/EKtDyorDQ==
Thread-topic: possible pcp atop rework
Hi Stan,

----- Original Message -----
> [...]
> > whether we should / shouldn't attempt a switch (essentially replacing the
> 
> I think this would be a definite improvement.  The line oriented tools are
> easier to mimic; but duplicating all the user presentation stuff is a
> headache.  I had peeked at this once and it seemed like photoproc was
> modularized and a dyninst clone would not be too bad.  photosyst didn't seem

[ apologies for inducing a context switch :) - I think you mean PCP API clone
rather than dyninst clone here? ]

> to be quite as modularized and I didn't look at acctphotoproc too much but
> it seemed like we could provide photoproc_dyn, photosyst_dyn, and
> acctphotoproc_dyn and things would work.  Does it look that way to you.  It
> would be a big improvement.
> 

Something like that, yes - I started hacking on it & there are places where
the existing modularisation works quite nicely for us; other places less so,
but nothing terrible so far.  I'll send a prototype around once I have some
basic functionality going.

Its interesting looking at the code - there's things that are well suited to
the abstractions PCP gives that seem to have been sought after for some time
(e.g there's #if HTTPSTATS sprinkled throughout).

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>