KMED(1)                     General Commands Manual                    KMED(1)



NAME
       kmed - Example of a remote kme daemon

SYNOPSIS
       kmed   [-c corefile] [-e endian] [-r] [-U port] [-D debug]

DESCRIPTION
       Kmed is an example of a remote daemon for kme(1).  Kmed communicates
       with kme over a socket using a simple custom UDP protocol called RW
       (for read-write).  The example version of kmed is useful as-is for many
       debugging situations.  kmed, however, may require customization in
       order to provide access to some types of hardware.

       Kmed can provide access for kme to more than one corefile (special
       device file) at a time.  From kme, the Nth corefile is accessed by
       prefixing the memory/device address with NN:, where NN is zero-based
       (i.e. 00; refers to the first corefile, 01: refers to the 2nd corefile,
       etc.);


       Command line options include:

       -c corefile(s)
              A colon-separated list of pathname(s) or device names which the
              remote kme will be given access to.  An unadorned pathname will
              be accessed using open(), close(), lseek(), read(), and write().


              Two alternative syntaxes are available for corefile, and both
              allow access to the corefile by using mmap() to map the corefile
              into the kmed process.  Mmap() is very useful when you want to
              access the /dev/mem special file on Linux.


              A fixed mmap()ing is selected with the syntax:
              corefile,offset,size.  In this case, size bytes at offset from
              the start of the corefile are mmap()ed.  This is useful if you
              want to access just a small region of a special device file.
              offset and size are interpreted in hexadecimal when prefixed
              with 0x, otherwise they are decimal.


              A floating mmap()ing is selected with the syntax:
              corefile,1,size.  In this case, size bytes are mmap()ed, but the
              offset of the mmap() will be determined based on the addresses
              that kme requests.  The offset may change over and over
              depending on what kme needs to display or modify.  This is
              useful if you want to access into a potentially large area of a
              special device file.  However, there may be performance
              implications if the addresses that kme needs bounce all over the
              place.  A well designed kme_defs file and kme display can
              minimize this problem.


              The default for corefile is /dev/kmem.

       -e endian
              Unfortunately, the original RW protocol was designed eons ago
              with no consideration given to the endianess of the protocol.
              This can cause problems when kme and kmed are running on
              computers with different endianess.  The endian option can be
              set to 0 (as-is), 1 (big-endian), or 2 (auto detect).  The
              default is to autodetect the endianess, and this usually works.

       -r     
              Open the corefile(s) for read access only.  The default is to
              open the corefile(s) for both read and write access.

       -U port
              The UDP port number to use for communications with kme.  The
              default is port 2773.

       -D level
              Set the debug output level for debugging kmed itself.  The
              default is 0 (no debugging output).

EXAMPLES
       Simple access to /dev/kmem:

              # kmed &

       The 1st corefile is /dev/kmem and is accessed using lseek(), read() and
       write().  The 2nd corefile is a floating mmap() of /dev/mem with a size
       of 4096 (one kernel memory page).

              # kmed -c /dev/kmem:/dev/mem,1,4096 &

RW PROTOCOL
       The definitive specification of the RW protocol is the header file
       kme.h and the source code for kme.c.  The protocol is UDP based
       (datagrams).

       When kme wants to read a memory location, it sends an rw_t packet to
       kmed and expects an rw_t packet in response.  It tries this a few
       times, and then gives up and displays ???????? for that location.  If
       the response was lost due to temporary network congestion it is not a
       big deal because kme will reissue the read request on the next display
       cycle.

       A similar thing happens with write requests.  But in case all of the
       retries of the write request are lost, the user will notice that the
       value hasn't changed and reissue the kme change command.  Obviously,
       this does not work well for hardware registers that are write-only.  In
       addition, network congestion could cause kmed to see two or more write
       requests before kme sees the reply from kmed.  For some hardware
       registers, multiple writes could cause unexpected behavior.

SEE ALSO
       kme(1)



BSD                            $Revision$ $Date$                       KMED(1)