filemon(4) [freebsd man page]
FILEMON(4) BSD Kernel Interfaces Manual FILEMON(4) NAME
filemon -- the filemon device SYNOPSIS
#include <dev/filemon/filemon.h> DESCRIPTION
The filemon device allows a process to collect file operations data of its children. The device /dev/filemon responds to two ioctl(2) calls. System calls are denoted using the following single letters: 'C' chdir(2) 'D' unlink(2) 'E' exec(2) 'F' fork(2), vfork(2) 'L' link(2), linkat(2), symlink(2), symlinkat(2) 'M' rename(2) 'R' open(2) for read 'S' stat(2) 'W' open(2) for write 'X' _exit(2) Note that 'R' following 'W' records can represent a single open(2) for R/W, or two separate open(2) calls, one for 'R' and one for 'W'. Note that only successful system calls are captured. IOCTLS
User mode programs communicate with the filemon driver through a number of ioctls which are described below. Each takes a single argument. FILEMON_SET_FD Write the internal tracing buffer to the supplied open file descriptor. FILEMON_SET_PID Child process ID to trace. RETURN VALUES
The ioctl() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. FILES
/dev/filemon EXAMPLES
#include <sys/types.h> #include <sys/stat.h> #include <sys/wait.h> #include <sys/ioctl.h> #include <dev/filemon/filemon.h> #include <fcntl.h> #include <err.h> #include <unistd.h> static void open_filemon(void) { pid_t child; int fm_fd, fm_log; if ((fm_fd = open("/dev/filemon", O_RDWR | O_CLOEXEC)) == -1) err(1, "open("/dev/filemon", O_RDWR)"); if ((fm_log = open("filemon.out", O_CREAT | O_WRONLY | O_TRUNC | O_CLOEXEC, DEFFILEMODE)) == -1) err(1, "open(filemon.out)"); if (ioctl(fm_fd, FILEMON_SET_FD, &fm_log) == -1) err(1, "Cannot set filemon log file descriptor"); if ((child = fork()) == 0) { child = getpid(); if (ioctl(fm_fd, FILEMON_SET_PID, &child) == -1) err(1, "Cannot set filemon PID"); /* Do something here. */ } else { wait(&child); close(fm_fd); } } Creates a file named filemon.out and configures the filemon device to write the filemon buffer contents to it. SEE ALSO
dtrace(1), ktrace(1), script(1), truss(1), ioctl(2) HISTORY
A filemon device appeared in FreeBSD 9.1. BSD
June 14, 2013 BSD
Check Out this Related Man Page
VKBD(4) BSD Kernel Interfaces Manual VKBD(4) NAME
vkbd -- the virtual AT keyboard interface SYNOPSIS
device vkbd DESCRIPTION
The vkbd interface is a software loopback mechanism that can be loosely described as the virtual AT keyboard analog of the pty(4), that is, vkbd does for virtual AT keyboards what the pty(4) driver does for terminals. The vkbd driver, like the pty(4) driver, provides two interfaces: a keyboard interface like the usual facility it is simulating (a virtual AT keyboard in the case of vkbd, or a terminal for pty(4)), and a character-special device ``control'' interface. The virtual AT keyboards are named vkbd0, vkbd1, etc., one for each control device that has been opened. The vkbd interface permits opens on the special control device /dev/vkbdctl. When this device is opened, vkbd will return a handle for the lowest unused vkbdctl device (use devname(3) to determine which). Each virtual AT keyboard supports the usual keyboard interface ioctl(2)s, and thus can be used with kbdcontrol(1) like any other keyboard. The control device supports exactly the same ioctl(2)s as the virtual AT keyboard device. Writing AT scan codes to the control device gener- ates an input on the virtual AT keyboard, as if the (non-existent) hardware had just received it. The virtual AT keyboard control device, normally /dev/vkbdctl<N>, is exclusive-open (it cannot be opened if it is already open) and is restricted to the super-user. A read(2) call will return the virtual AT keyboard status structure (defined in <dev/vkbd/vkbd_var.h>) if one is available; if not, it will either block until one is or return EWOULDBLOCK, depending on whether non-blocking I/O has been enabled. A write(2) call passes AT scan codes to be ``received'' from the virtual AT keyboard. Each AT scan code must be passed as unsigned int. Although AT scan codes must be passes as unsigned ints, the size of the buffer passed to write(2) still should be in bytes, i.e., static unsigned int codes[] = { /* Make Break */ 0x1e, 0x9e }; int main(void) { int fd, len; fd = open("/dev/vkbdctl0", O_RDWR); if (fd < 0) err(1, "open"); /* Note sizeof(codes) - not 2! */ len = write(fd, codes, sizeof(codes)); if (len < 0) err(1, "write"); close(fd); return (0); } Write will block if there is not enough space in the input queue. The control device also supports select(2) for read and write. On the last close of the control device, the virtual AT keyboard is removed. All queued scan codes are thrown away. SEE ALSO
kbdcontrol(1), atkbdc(4), psm(4), syscons(4) CAVEATS
The vkbd interface is a software loopback mechanism, and, thus ddb(4) will not work with it. Current implementation of the syscons(4) driver can accept input from only one keyboard, even if it is virtual. Thus it is not possible to have both wired and virtual keyboard to be active at the same time. It is, however, in principal possible to obtain AT scan codes from the different sources and write them into the same vir- tual keyboard. The virtual keyboard state synchronization is the user's responsibility. HISTORY
The vkbd module was implemented in FreeBSD 6.0. AUTHORS
Maksim Yevmenkin <m_evmenkin@yahoo.com> BSD
August 12, 2004 BSD