Release notes for LibGTop 1.0.

This commit is contained in:
Martin Baulig
1999-02-16 14:41:58 +00:00
parent 896729108c
commit 1086496f93

View File

@@ -1,13 +1,13 @@
RELEASE NOTES FOR LIBGTOP 0.25 STABLE
=====================================
RELEASE NOTES FOR LIBGTOP 1.0 STABLE
====================================
OVERVIEW
--------
LibGTop is a library that read information about processes and the running
systems. This information include:
LibGTop is a library that read information about processes and the
running systems. This information include:
General System Information
General System Information:
cpu - CPU Usage
mem - Memory Usage
@@ -21,6 +21,11 @@ shm_limits - Shared Memory Limits
msg_limits - Message Queue Limits
sem_limits - Semaphore Set Limits
Network:
netload - Network load
ppp - PPP statistics
Process List:
proclist - List of processes
@@ -41,6 +46,7 @@ proc_segment - text_rss,shlib_rss,data_rss,stack_rss,dirty_size
Process maps:
proc_args - Command line arguments
proc_map - Process map (/proc/<pid>/maps under Linux)
File system usage:
@@ -51,95 +57,106 @@ fsusage - File system usage
PORTABILITY:
-----------
LibGtop is designed to be as portable as possible. None of the functions
and retrieved information should be specific to a specific operating
system. So you only need to port the system dependent part of the library
to a new system and all application programs can then use libgtop on this
new system.
LibGTop is designed to be as portable as possible. None of the
functions and retrieved information should be specific to a specific
operating system. So you only need to port the system dependent part
of the library to a new system and all application programs can then
use libgtop on this new system.
CLIENT/SERVER MODEL:
-------------------
Some systems like DEC OSF/1 or BSD require special priviledges for the calling
proces to fetch the required information (SUID root/SGID kmem). To solve this
problem, I designed a client/server model which makes a call to a SUID/SGID
server which fetches the required information whenever it is required. This
server is only called for features that really require priviledges, otherwise
the sysdeps code is called directory (every user can get the CPU usage on
DEC OSF/1, but only root can get information about processes other than the
Some systems like DEC OSF/1 or BSD require special privileges for the
calling process to fetch the required information (SUID root/SGID
kmem). To solve this problem, I designed a client/server model which
makes a call to a SUID/SGID server which fetches the required
information whenever it is required. This server is only called for
features that really require privileges, otherwise the sysdeps code
is called directory (every user can get the CPU usage on DEC OSF/1,
but only root can get information about processes other than the
current one).
There is also some kind of daemon which can be used to fetch information from
remote systems (still experimental). This daemon normally runs as nobody and
calls the SUID/SGID itself when needed.
There is also some kind of daemon which can be used to fetch
information from remote systems (still experimental). This daemon
normally runs as nobody and calls the SUID/SGID itself when needed.
GNOME APPLETS:
--------------
LIBGTOP AND GNOME:
-----------------
There are some applets and applications which already use LibGTop. They can
be found in the `libgtop-apps' module in the GNOME CVS tree:
LibGTop is currently used in various places in the GNOME Project,
for instance in some of the applets in gnome-core and - of cause -
this ultra-cool application called GTop ...
* Applets: cpuload, cpumemusage - they need LibGTop to get their information
on all systems other than Linux.
Although LibGTop is not specific to GNOME and under LGPL license, I
spent most my time during the last months to work in the GNOME project
so this is the primary use for LibGTop (and currently the only one).
* Applets: diskusage - just uses the mountlist/fsusage features of LibGTop,
the one in gnome-core also works on other systems.
However, you can also give its configure.in script the `--without-gnome'
parameter and then use it fully without GNOME in your own applications.
* Applets: multiload - I enhanced the cpuload applet a little bit, it is
now a multi applet and can display CPU, Memory and
Swap usages.
LIBGTOP AND GNOME - PART II:
---------------------------
GTOP:
----
LibGTop was tested with FreeBSD 3.0 but it should also work with
FreeBSD 2.2.7, NetBSD and OpenBSD.
This cool GNOME app has been ported to use LibGTop. It can be found in
`libgtop-apps/gtop' in the GNOME CVS tree.
Currently my primary aim is to help the GNOME people with our 1.0 release
so I won't have much time to test it with any other system than Linux.
You can now use nearly the full functionality of GTop on FreeBSD !
However, I consider FreeBSD, NetBSD and OpenBSD as supported systems for
LibGTop and whenever I get bug reports I will do my best to fix them as
quickly as possible.
PLATTFORM SPECIFIC NOTES FOR LINUX:
PLATFORM SPECIFIC NOTES FOR LINUX:
==================================
Under Linux, LibGTop should work without problems and read everything
from /proc.
There is also an experimental kernel interface to read this information
directly from the kernel with a system call - but this is still experimental
and not well tested while I made this release.
LibGTop 0.25 also had an experimental kernel interface to read this
information directly from the kernel with a system call - but I have
currently dropped support for this as I am too busy with GNOME
development to keep current with kernel hacking.
PLATTFORM SPECIFIC NOTES FOR FREEBSD:
PLATFORM SPECIFIC NOTES FOR SOLARIS:
====================================
LibGTop should now work under FreeBSD and give you the full functionality
of GTop.
Since so many people were asking me about this:
LibGTop currently does not have any support for Solaris, and it will
never have until some volunteer writes the code for it. I can't do this
myself since I do not have any machine to test it on.
PLATFORM SPECIFIC NOTES FOR BSD:
=================================
There are a few caveats:
* You need to manually make the `$(prefix)/bin/libgtop_server' SGID to kmem
after installation and mount the /proc filesystem of FreeBSD
(/proc/<pid>/mem is used withing kvm_uread ()).
* You need to manually make the `$(prefix)/bin/libgtop_server' SGID to
kmem after installation and mount the /proc file system of FreeBSD
(/proc/<pid>/mem is used within kvm_uread ()).
* To get the filenames of the process maps displayed in GTop, you need to
configure with the `--with-libgtop-inodedb' option (you need GDBM for this
to work).
* To get the filenames of the process maps displayed in GTop, you need
to configure with the `--with-libgtop-inodedb' option (you need GDBM
for this to work).
* You have then to create an inode database which is used to look up to
filenames. This is done using the `mkinodedb' program which comes along
with libgtop.
You have then to create an inode database which is used to look up
filenames. This is done using the `mkinodedb' program which comes
along with libgtop.
See the file src/inodedb/README for details:
The `mkinodedb' program which is build in this directory takes two
command line arguments: the full pathname of the database to be created
and the name of a configuration file consisting of directory and file names
each on a line by itself - see `/etc/ld.so.conf' for an example.
command line arguments: the full pathname of the database to be
created and the name of a configuration file consisting of directory
and file names each on a line by itself - see `/etc/ld.so.conf' for
an example.
Putting a directory name in this file means all regular files found in this
directory are included in the database, but it will not recursively descend
into subdirectories (for instance, we want everythink in `/usr/lib' but not
every single file in `/usr/lib/sgml'). You can also use filenames to include
a single file.
Putting a directory name in this file means all regular files found
in this directory are included in the database, but it will not
recursively descend into subdirectories (for instance, we want
everything in `/usr/lib' but not every single file in `/usr/lib/sgml').
You can also use filenames to include a single file.
Have fun,