[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Process and performance monitor for KDE
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-06-23 9:05:27
[Download RAW message or body]

On Tue, 22 Jun 1999, Chris Schlaeger wrote:

> On Tue, Jun 22, 1999 at 02:13:15PM +0200, Simon Hausmann wrote:
> > On Tue, 22 Jun 1999, Chris Schlaeger wrote:
> > 
> > > On Tue, Jun 22, 1999 at 10:09:06AM +0200, Waldo Bastian wrote:
> > > > "Dirk A. Mueller" wrote:
> > > [...]
> > > > > As you might probably remember from my experiments in ktop, scandir()
> > > > > has a porting issue. I think we can replace it with QDir(), can't we?
> > > > 
> > > > Yes.
> > > > 
> > > > Given the fact that at least two applications scan /proc, it might
> > > > be a good idea to see if we can put some functions in kdelibs
> > > > which do that for you. 
> > > > Like QList<something> getProcessList(bool allProcesses)
> > > 
> > > I have such a function in KTop. Actually it's not just a function but
> > > a class. Have a look at kdeutils/ktop/OSProcessList.h. The problem is
> > > that it only works on Linux 2.x and FreeBSD right now. Not all UNIXes
> > > have a /proc filesystem (e.g. FreeBSD) and some require special
> > > privileges (e.g. Solaris < 2.6) to access the process list. I have
> > > tried to hide all this behind a common interface class but so far
> > > nobody volunteered to port it to other platforms.
> > > 
> > > I'm thinking about restructuring this for the next KTop release. I
> > > want to write a little daemon that provides the process table and
> > > performance information (CPU load, memory usage, network load and the
> > > like). This will be a plain C program to avoid security problems on
> > > the platforms that require special privileges. The front end (KTop)
> > > can then connect to local and remote daemons to display process and
> > > performance information. If other KDE apps want to access this
> > > information as well we might want to put the back-end part in a
> > > library. BTW, is anybody aware of a GPLed (or simular) version of such a
> > > performance monitor daemon?  So far I've only found proprietary
> > > versions. :((
> > 
> > What about making this performance monitor a CORBA server instead of yet
> > another daemon? 
> > Advantages:
> > 1) You don't have to deal with the IPC issue, because CORBA is your friend
> > 2) It would be accessible for all KDE apps through kded
> > 3) One could even access it from KScripts! (would need kded support in
> >    libkscript -> no problem)
> > 4) It would be launched on demand only -> save resources
> 
> Definitely an interesting idea! Although I have two conernes: security
> and the need to have CORBA support on all machines I want to
> monitor. Are you coming to the Linux Tag? We might talk about this a
> bit more there.

1) Security: kded will soon talk to it's client through pipes, rather
than via inet sockets. This should fulfill security needs then I think.

2) CORBA support: Well, KDE requires CORBA anyway... Or do you want to run
the monitor on non-kde machines and "talk" to the monitor over a network?

3) LinuxTag: Unfortunately I don't have time to come :-(

Ciao,
  Simon

--
*help*! What can I do against this evil dangerous beast? Is there an
anti-virus plugin from Micosoft available??

*** *** *** Hi! I'm a .signature virus! *** *** ***
Copy me into your .signature file to help me spread!

[prev in list] [next in list] [prev in thread] [next in thread]