libgtop-GNOME-2-0-branch moved to HEAD.

2003-10-19  Carlos Perelló Marín <carlos@gnome.org>

	* libgtop-GNOME-2-0-branch moved to HEAD.
This commit is contained in:
Carlos Perelló Marín
2003-10-19 16:10:39 +00:00
committed by Carlos Perelló Marín
parent 5e28a55218
commit bae16b467f
148 changed files with 29273 additions and 26459 deletions

View File

@@ -8,4 +8,3 @@ auto-macros.texi
version.texi
stamp-vti
*.html *.pdf
*.info-*

View File

@@ -1,10 +1,13 @@
2002-01-09 Darin Adler <darin@bentspoon.com>
2002-03-12 James Henstridge <james@daa.com.au>
* Makefile.am: Fix build breakage caused by bad MAKEINFO change.
* Makefile.am (MAKEINFO): using += seems to screw up the build
with newer automakes. Set it explicitly (using @MAKEINFO@) seems
to be compatible with both.
2000-02-05 Martin Baulig <martin@home-of-linux.org>
2001-11-26 Abel Cheung <maddog@linux.org.hk>
* reference.texi: Started to update documentation.
* libgtop.texi, Makefile.am: Renamed to libgtop2.texi
* about.texi: Very minor update.
1999-10-18 Martin Baulig <martin@home-of-linux.org>
@@ -15,22 +18,7 @@
1999-09-29 Martin Baulig <martin@home-of-linux.org>
* Makefile.am: Reverted Timur's commit.
(MAKEINFO): Add `-I @libgtop_top_builddir@/doc' here. This still
creates libgtop.info in srcdir, but that's an automake problem.
Tue Jun 15 15:59:50 1999 Timur Bakeyev <mc@bat.ru>
* Makefile.am: Force `auto-macros.texi' to be created in $(srcdir),
as, otherwise, makeinfo is unable to find it, if srcdir != builddir.
That's a buggy solution, as spoils srcdir, but, as libgtop.info also
created in srcdir - this is acceptable. Both SHOULD be fixed!
1999-05-28 Martin Baulig <baulig@Stud.Informatik.Uni-Trier.DE>
* internals.texi: New file documenting LibGTop internals.
* reference.texi: Started to document all library functions and
finished the sysdeps and common references.
* Makefile.am (MAKEINFO): Add `-I @libgtop_top_builddir@/doc' here.
1999-05-16 Martin Baulig <martin@home-of-linux.org>

View File

@@ -1,8 +1,8 @@
info_TEXINFOS = libgtop.texi
info_TEXINFOS = libgtop2.texi
libgtop_TEXINFOS = libgtop.texi about.texi reference.texi \
libgtop2_TEXINFOS = libgtop2.texi about.texi reference.texi \
auto-macros.texi version.texi main.texi \
white-paper.texi internals.texi
white-paper.texi
MAKEINFO = @MAKEINFO@ -I @libgtop_top_builddir@/doc
@@ -11,7 +11,7 @@ EXTRA_DIST = auto-macros.texi.in
auto-macros.texi: auto-macros.texi.in Makefile
## Use sed and then mv to avoid problems if the user interrupts.
sed -e 's#\%LIBGTOP_LIBDIR\%#$(libdir)#g' \
-e 's#\%LIBGTOP_INCLUDEDIR\%#$(includedir)#g' \
-e 's#\%LIBGTOP_INCLUDEDIR\%#$(includedir)/libgtop-2.0#g' \
-e 's#\%LIBGTOP_DATADIR\%#$(datadir)#g' \
-e 's#\%LIBGTOP_EXTRA_LIBS\%#$(LIBGTOP_EXTRA_LIBS)#g' \
-e 's#\%LIBGTOP_LIBS\%#$(LIBGTOP_LIBS)#g' \

View File

@@ -7,9 +7,10 @@ and information about running Processes.
On Systems like Solaris or Digital Unix where you need special privileges to
get those data, it uses a setuid/setgid server to do so.
Even if LibGTop is a part of the GNOME desktop environment (@uref{http://www.gnome.org}),
the main interface of LibGTop is totally independent from any particular desktop environment,
so you can also use it as a standalone library in any piece of GPLed software.
Even if LibGTop is a part of the GNOME desktop environment
(@uref{http://www.gnome.org}), the main interface of LibGTop is totally
independent from any particular desktop environment, so you can also use it
as a standalone library in any piece of GPLed software.
@menu
* Availability:: Where to get LibGTop
@@ -32,10 +33,10 @@ latest release tarballs from
@noindent
or any of its mirror sites.
The latest stable version of LibGTop is 1.0.1 which is also the one that comes
together with GNOME 1.0. In CVS, there is a @code{LIBGTOP_STABLE_1_0} branch
which is rooted at the @code{LIBGTOP_1_0_1} tag while actual development occurs
in the @code{HEAD} which currently has version 1.1.0.
The latest stable version of LibGTop is 1.0.12 which is also the one that comes
together with GNOME 1.0. It belongs to @code{LIBGTOP_STABLE_1_0} branch in CVS.
Actual development occurs in the @code{libgtop-GNOME-2-0-port} which is
currently versioned 1.90.0.
@node Supported Platforms, Mailing List, Availability, About
@section Supported Platforms
@@ -46,7 +47,7 @@ The stable branch currently supports the following platforms:
@item All versions of Linux
LibGTop was tested under Linux 2.0.x and 2.2.x on the ix86 and the alpha, but
it should also work without problems on SparcLinux.
it should also work without problems on SparcLinux or Linux 2.4.x.
Note: I'm speaking of the Linux kernel here, not the GNU/Linux operating system.
@@ -115,6 +116,7 @@ me a lot in the early beginning.
@item Timur Bakeyev for the BSDI port.
@item Drazen Kacar and the other people on the LibGTop development mailing
list for the Solaris port.
@item Kevin Vandersloot for the effort to port to GNOME 2.0.
@item All people sending me patches, having good ideas, ...
@item Everyone I have forgotten in this list ...
@end itemize

View File

@@ -4,23 +4,8 @@
* About:: About LibGTop
* White Paper:: LibGTop White Paper
* Reference Manual:: LibGTop Reference Manual
* LibGTop Internals:: LibGTop Internals
@detailmenu --- The Detailed Node Listing ---
--- The Detailed Node Listing ---
About LibGTop
@@ -33,7 +18,6 @@ LibGTop White Paper
* Introduction:: Introduction
* Overview:: Overview
* Servers and Daemons:: Servers and Daemons
Overview
@@ -45,8 +29,6 @@ LibGTop Reference Manual
* System Dependent:: System Dependent Functions.
* Common Functions:: Common Functions.
* Library Functions:: Library Functions.
* Generic Structures:: Generic Structures.
* Enums and Typedefs:: Enums and Typedefs.
System Dependent Functions
@@ -65,7 +47,6 @@ System Dependent Functions
* glibtop_proc_segment:: Process Segment Information.
* glibtop_proc_args:: Process Arguments.
* glibtop_proc_map:: Process Memory Maps.
* glibtop_netinfo:: Network Information.
* glibtop_netload:: Network Load.
* glibtop_ppp:: PPP Usage.
@@ -79,40 +60,9 @@ Library Functions
* glibtop_init:: Server Initialization.
* glibtop_sysdeps:: Server Sysdeps.
* Library Parameters:: Library Parameters.
Generic Structures
* glibtop_ifaddr:: Interface Address.
Enums and Typedefs
* Network Interfaces:: Network Interfaces.
* Address Scope:: Address Scope (IPv6).
Network Interfaces
* Transport Methods:: Transport Methods.
* Interface Flags:: Interface Flags.
LibGTop Internals
* General Internals:: General Internals
* Sysdeps Internals:: Sysdeps Internals
General Internals
* glibtop:: The server structure
Sysdeps Internals
* glibtop_open_s:: Non-privileged initializations
* glibtop_close_s:: Non-privileged cleanups
@end detailmenu
@end menu
@include about.texi
@include white-paper.texi
@include reference.texi
@include internals.texi

View File

@@ -1,12 +1,10 @@
@node Reference Manual, LibGTop Internals, White Paper, Top
@node Reference Manual, , White Paper, Top
@chapter LibGTop Reference Manual
@menu
* System Dependent:: System Dependent Functions.
* Common Functions:: Common Functions.
* Library Functions:: Library Functions.
* Generic Structures:: Generic Structures.
* Enums and Typedefs:: Enums and Typedefs.
@end menu
@node System Dependent, Common Functions, Reference Manual, Reference Manual
@@ -28,7 +26,6 @@
* glibtop_proc_segment:: Process Segment Information.
* glibtop_proc_args:: Process Arguments.
* glibtop_proc_map:: Process Memory Maps.
* glibtop_netinfo:: Network Information.
* glibtop_netload:: Network Load.
* glibtop_ppp:: PPP Usage.
@end menu
@@ -1114,7 +1111,7 @@ the lenght of this string is returned in the @code{size} field.
Remember to @code{glibtop_free} the returned string to avoid a memory leak.
@page
@node glibtop_proc_map, glibtop_netinfo, glibtop_proc_args, System Dependent
@node glibtop_proc_map, glibtop_netload, glibtop_proc_args, System Dependent
@subsection Process Memory Maps
Library function @code{glibtop_get_proc_map}:
@@ -1201,87 +1198,7 @@ Constants for the @code{perm} member:
@end example
@page
@node glibtop_netinfo, glibtop_netload, glibtop_proc_map, System Dependent
@subsection Network Information
Library function @code{glibtop_get_netinfo}:
@example
@cartouche
glibtop_ifaddr *
glibtop_get_netinfo (glibtop_array *array, glibtop_netinfo *buf,
const char *interface, u_int64_t transport);
glibtop_ifaddr *
glibtop_get_netinfo_l (glibtop *server, glibtop_array *array,
glibtop_netinfo *buf, const char *interface,
u_int64_t transport);
@end cartouche
@end example
Declaration of @code{glibtop_ifaddr} in @file{<glibtop/interfaces.h>}:
@example
@cartouche
typedef struct _glibtop_ifaddr glibtop_ifaddr;
struct _glibtop_ifaddr
@{
u_int64_t flags,
transport;
u_int8_t addr_len,
address [GLIBTOP_IFADDR_LEN];
u_int64_t subnet,
scope;
@};
@end cartouche
@end example
Declaration of @code{glibtop_netinfo} in @file{<glibtop/netinfo.h>}:
@example
@cartouche
typedef struct _glibtop_netinfo glibtop_netinfo;
struct _glibtop_netinfo
@{
u_int64_t flags,
if_flags,
transport,
mtu;
@};
@end cartouche
@end example
Returns information about network interface @code{interface}.
@table @code
@item interface
The network interface you want to get information about (for instance
@samp{eth0}).
@item transport
Bitmask specifying about which transport methods you want to get information
or @code{GLIBTOP_TRANSPORT_ALL} if you want information about all possible
transport methods (@pxref{Transport Methods}).
@end table
On success, the following fields in @code{glibtop_netinfo} are set:
@table @code
@item if_flags
Interface flags (@pxref{Interface Flags}).
@item transport
Bitmask of all transport methods which are currently supported on the
selected interface (@pxref{Transport Methods}).
@item mtu
Maximum Transfer Unit (MTU)
@end table
Additionally, an array of @code{glibtop_ifaddr} structures is returned
(@pxref{glibtop_ifaddr}).
@page
@node glibtop_netload, glibtop_ppp, glibtop_netinfo, System Dependent
@node glibtop_netload, glibtop_ppp, glibtop_proc_map, System Dependent
@subsection Network Load
Library function @code{glibtop_get_netload}:
@@ -1597,7 +1514,7 @@ Free file nodes.
Blocks are usually 512 bytes.
@page
@node Library Functions, Generic Structures, Common Functions, Reference Manual
@node Library Functions, , Common Functions, Reference Manual
@section Library Functions
This are general library functions which can be used to get information
@@ -1888,159 +1805,3 @@ Abort if the library fails to get some of the required features. This
should not be used by applications.
@end table
@node Generic Structures, Enums and Typedefs, Library Functions, Reference Manual
@section Generic Structures
@menu
* glibtop_ifaddr:: Interface Address.
@end menu
@node glibtop_ifaddr, , Generic Structures, Generic Structures
@subsection Interface Addresses
The @code{glibtop_ifaddr} structure contains information about a network
interface.
It is declared in @file{<glibtop/interfaces.h>}:
@example
@cartouche
typedef struct _glibtop_ifaddr glibtop_ifaddr;
struct _glibtop_ifaddr
@{
u_int64_t flags,
transport;
u_int8_t addr_len,
address [GLIBTOP_IFADDR_LEN];
u_int64_t subnet,
scope;
@};
@end cartouche
@end example
The contents of this structure depends on the @code{transport} field -
for instance a single network interface can have both an IPv4 address
and several IPv6 ones. This is why functions like @code{glibtop_get_netinfo}
return an array of @code{glibtop_ifaddr} structures.
In general, the fields of the @code{glibtop_ifaddr} structure have the
following meaning:
@table @code
@item transport
The "interface address" from the @code{address} field is only valid for
this transport method (@pxref{Transport Methods}).
@item addr_len
Length of the interface address in the @code{address} field in bytes.
@item address
This is one of the "interface address" for the selected network interface
which is used with the transport method from the @code{transport} field.
@item subnet
The meaning of this field depends on the transport method and is currently
only used for IPv4 (where it contains the current subnet mask) and for IPv6
(where it contains the address length in bits).
@item scope
This is only used for IPv6 and contains the address scope
(@pxref{Address Scope}).
@end table
@node Enums and Typedefs, , Generic Structures, Reference Manual
@section Enums and Typedefs
@menu
* Network Interfaces:: Network Interfaces.
* Address Scope:: Address Scope (IPv6).
@end menu
@node Network Interfaces, Address Scope, Enums and Typedefs, Enums and Typedefs
@subsection Network Interfaces
@menu
* Transport Methods:: Transport Methods.
* Interface Flags:: Interface Flags.
@end menu
@node Transport Methods, Interface Flags, Network Interfaces, Network Interfaces
@subsubsection Transport Methods
The following transport methods are defined in @file{<glibtop/interfaces.h>}:
@example
@cartouche
enum _glibtop_transport @{
GLIBTOP_TRANSPORT_DEFAULT = 0,
GLIBTOP_TRANSPORT_IPV4 = 1 << 0,
GLIBTOP_TRANSPORT_IPV6 = 1 << 1,
GLIBTOP_TRANSPORT_IPX = 1 << 2,
GLIBTOP_TRANSPORT_X25 = 1 << 3,
GLIBTOP_TRANSPORT_DECNET = 1 << 4,
GLIBTOP_TRANSPORT_APPLETALK = 1 << 5,
GLIBTOP_TRANSPORT_NETBEUI = 1 << 6,
@};
@end cartouche
@end example
There is a @code{GLIBTOP_TRANSPORT_ALL} constant which can be used
when you want information about all possible transport methods:
@example
@cartouche
#define GLIBTOP_TRANSPORT_ALL GLIBTOP_UNLIMITED
@end cartouche
@end example
@node Interface Flags, , Transport Methods, Network Interfaces
@subsubsection Interface Flags
This is defined in @file{<glibtop/interfaces.h>}:
@example
@cartouche
enum _glibtop_interface_flags @{
GLIBTOP_IF_FLAGS_UP = 1,
GLIBTOP_IF_FLAGS_BROADCAST,
GLIBTOP_IF_FLAGS_DEBUG,
GLIBTOP_IF_FLAGS_LOOPBACK,
GLIBTOP_IF_FLAGS_POINTOPOINT,
GLIBTOP_IF_FLAGS_RUNNING,
GLIBTOP_IF_FLAGS_NOARP,
GLIBTOP_IF_FLAGS_PROMISC,
GLIBTOP_IF_FLAGS_ALLMULTI,
GLIBTOP_IF_FLAGS_OACTIVE,
GLIBTOP_IF_FLAGS_SIMPLEX,
GLIBTOP_IF_FLAGS_LINK0,
GLIBTOP_IF_FLAGS_LINK1,
GLIBTOP_IF_FLAGS_LINK2,
GLIBTOP_IF_FLAGS_ALTPHYS,
GLIBTOP_IF_FLAGS_MULTICAST
@};
@end cartouche
@end example
They are used as a bit mask like this:
@example
u_int64_t if_flags;
if_flags = (1L << GLIBTOP_IF_FLAGS_UP) | (1L << GLIBTOP_IF_FLAGS_RUNNING);
@end example
@node Address Scope, , Network Interfaces, Enums and Typedefs
@subsection Address Scope
This is defined in @file{<glibtop/interfaces.h>} for the IPv6 address scope:
@example
@cartouche
enum _glibtop_ipv6_scope @{
GLIBTOP_IPV6_SCOPE_GLOBAL = 0,
GLIBTOP_IPV6_SCOPE_LOOPBACK = 1 << 1,
GLIBTOP_IPV6_SCOPE_LINKLOCAL = 1 << 2,
GLIBTOP_IPV6_SCOPE_SITELOCAL = 1 << 3,
GLIBTOP_IPV6_SCOPE_COMPATv4 = 1 << 4,
GLIBTOP_IPV6_SCOPE_UNKNOWN = 1 << 5
@};
@end cartouche
@end example

View File

@@ -4,7 +4,6 @@
@menu
* Introduction:: Introduction
* Overview:: Overview
* Servers and Daemons:: Servers and Daemons
@end menu
@node Introduction, Overview, White Paper, White Paper
@@ -48,7 +47,7 @@ since there's more than just one single program that wants to use them - for
instance @code{gtop} and the @code{multiload}, @code{cpumemusage} and
@code{netload} panel applets.
@node Overview, Servers and Daemons, Introduction, White Paper
@node Overview, , Introduction, White Paper
@section Overview
This section should give you a short overview on how LibGTop was developed, which
@@ -89,48 +88,3 @@ only contains the @dfn{features} which need privileges.
Whenever we do not need any privileges to get all the data for some of the requested
structures (here called @dfn{features}) the library calls the sysdeps code directly
rather than using the server.
@node Servers and Daemons, , Overview, White Paper
@section Servers and Daemons
LibGTop gives you the possibility to use different LibGTop "servers" and
"daemons" in your application.
Normally you do not need to worry about this things since LibGTop auto-
matically opens a pipe to its server it it's required, but this can also
be customized to fit your needs.
For instance if you have a small applet which is only interested in disk
usage there's no need to fork a separate server process since you don't
need any privileges to get them on any of the supported systems. This can
be archieved with a special call to @code{glibtop_init_r} on startup.
There's also an option to tell @code{glibtop_init_r} that you're only
interested in several features - for instance cpu and memory usage. In
this case LibGTop will only fork a server process if it's required to get
cpu and memory.
You can also tell @code{glibtop_init_r} to start the server only on demand,
this might become useful in command-line based programs. For graphical
applications it's normally best to start the server directly during their
initialization. The same applies for any time critical applications (since
@code{fork} is an expensive operation on some systems this may lead to
incorrect statistics).
LibGTop also allows you to talk to a remote machine using the
@dfn{LibGTop daemon}. This daemon is based on @code{gnuserv} from
GNU Emacs and should be run as an unprivileged user. It has support
for either @code{xauth} or host based authorization.
This daemon itself behaves like a LibGTop client application, i.e. it
forks a server process if this is required.
The main use for this daemon is when you want to monitor a machine which
is either very slow or has very low disk space. In this case you don't need
to install the whole client application (for instance GTop) on the remote
machine but only a very small (maybe also statically linked) executable and
run the graphical application on a more powerful machine.
It can also be used to monitor a remote machine over a very slow link such
as a dialup connection since the conversation between LibGTop client and
daemon uses much less bandwith than an ordinary X11 connection.