Release notes for LibGTop 1.0.

1 files changed, 79 insertions, 62 deletions

diff --git a/RELNOTES-1.0 b/RELNOTES-1.0
index d00152e4..e2708f1f 100644
--- a/RELNOTES-1.0
+++ b/RELNOTES-1.0
@@ -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.
-
-  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.
+  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
+  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,