Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

filemon(4) [freebsd man page]

FILEMON(4)						   BSD Kernel Interfaces Manual 						FILEMON(4)

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

IO(4)                                                      BSD Kernel Interfaces Manual                                                      IO(4)

io -- I/O privilege file SYNOPSIS
device io #include <sys/types.h> #include <sys/ioctl.h> #include <dev/io/iodev.h> #include <machine/iodev.h> struct iodev_pio_req { u_int access; u_int port; u_int width; u_int val; }; DESCRIPTION
The special file /dev/io is a controlled security hole that allows a process to gain I/O privileges (which are normally reserved for kernel- internal code). This can be useful in order to write userland programs that handle some hardware directly. The usual operations on the device are to open it via the open(2) interface and to send I/O requests to the file descriptor using the ioctl(2) syscall. The ioctl(2) requests available for /dev/io are mostly platform dependent, but there are also some in common between all of them. The IODEV_PIO is used by all the architectures in order to request that an I/O operation be performed. It takes a 'struct iodev_pio_req' argu- ment that must be previously setup. The access member specifies the type of operation requested. It may be: IODEV_PIO_READ The operation is an "in" type. A value will be read from the specified port (retrieved from the port member) and the result will be stored in the val member. IODEV_PIO_WRITE The operation is a "out" type. The value will be fetched from the val member and will be written out to the specified port (defined as the port member). Finally, the width member specifies the size of the operand to be read/written, expressed in bytes. In addition to any file access permissions on /dev/io, the kernel enforces that only the super-user may open this device. LEGACY
The /dev/io interface used to be very i386 specific and worked differently. The initial implementation simply raised the IOPL of the current thread when open(2) was called on the device. This behaviour is retained in the current implementation as legacy support for both i386 and amd64 architectures. SEE ALSO
close(2), i386_get_ioperm(2), i386_set_ioperm(2), ioctl(2), open(2), mem(4) HISTORY
The io file appeared in FreeBSD 1.0. BSD June 01, 2010 BSD
Man Page