/dev/rpl is a character device file which returns the data captured from ttys through the rpldev kernel module. It has no fixed device number, since it asks the misc driver subsystem (char-major-10) to assign it a dynamic one.

This is a little feature rather than a bug. rpld will automatically read /sys/module/rpldev/Minor_nr or /proc/misc for the minor number and creates a device file in /var/run/ or its working directory. You should not worry about the minor number and creating a device node, that's the idea behind. (udev is in a bad shape ATM.)

However, the hotplug subsystem and udev might happen to create /dev/rpl when the kernel module is loaded, for the misc subsystem calls the hotplug layer. /dev/rpl is not touched if it exists, and since the userspace hotplug components will be shutdown before the module is unloaded, the node will be kept (unless /dev is on a ram disk). If it exists, make sure nobody else than root can read it, usually mode 0400.

Under FreeBSD, the rpldev module will devote a whole major number to itself, and make use of devfs to pop up as /dev/rpl. rpld will have no problems in finding the right thing on any of the supported OSes.

The rpldev module has the following options. Some of them may be changed dynamically at run-time via /sys/module/rpldev/.

I have not found any way for passing or modifying options under BSD, so you are stuck with a fixed 32K buffer.

Everytime the kernel functions for reading/writing from/to a terminal are executed, the call chain is extened into the rpldev hooks, i.e. an external function in the rpldev kernel module is called, which transfers the tty buffer into so-called packets, which are then returned as /dev/rpl is read.

A packet consists of a device number, magic byte (always 0xEE), size of the data, and of course, the data itself. All fields are little-endian and packed, i.e. there are no alignment gaps. It can be represented in this C struct:

The data itself is actually not included in the struct, since it is of dynamic length. For further reference, the struct alone will be called packet header, whereas packet header plus data (or payload) equals packet. There are no byte-aligning gaps between the members, i.e. it is a so-called packed structure. (No pun between packet and packed.)

The .dev member contains the device number on which the event occurred. Since both the master and the slave side of a pty pair can generate events, and we usually do not need the master side events, they are already dropped at the kernel level.

The device field is made up of the in-kernel dev_t thing in Linux 2.6, i.e. major is in bits 20-31, minor in bits 0-19, all little-endian. BSD rpldev will convert device numbers to the scheme used in Linux. As things have come, a truncation is involved, in which minors greater than 1048575 will be truncated.

The following event types exist:

EVT_INIT is generated is generated when the tty is initialized. This usually happens when you open() it the first time.

EVT_OPEN, EVT_READ, EVT_WRITE and EVT_CLOSE are generated whenever an open(), read(), write() or close(), respectively, is done.

EVT_DEINIT is generated when the tty is about to be deinitialized. In theory, you do not know when a device will do this (i.e. deferred deinit). However, you've got the Kernel sources, and as such know when it actually happens (e.g. when the last open filedescriptor is closed).

EVT_IOCTL is generated when ioctl() is called on a tty. The data will consist of one uint32_t describing the cmd parameter. (See ioctl(2).)