Device Driver Support

Memory-to-memory network adapters virtualize the NIC hardware and are directly accessible from user space. One such example is VI [5] where the NIC implements a number of VI contexts. Each VI is the equivalent of a socket in traditional network protocols, except that a VI is directly supported by the NIC hardware and usually has a memory-mapped rather than a system call interface. The requirement to create multiple logical instances of a device, each with its own private state (separate from the usual device softcopy state) and to map those devices in user address spaces requires new support from BSD kernels.

Network driver model. Network drivers in BSD systems are traditionally accessed through sockets and do not appear in the filesystem name space (i.e. under /dev). User-level libraries for memory-to-memory network transports require these devices to be opened and closed multiple times with each opened instance appearing as a separate logical device maintaining private state, and be memory-mapped. FreeBSD until recently provided rudimentary support for this through the devfs file system which is being abandoned. Devfs allows logical instances of a device to be dynamically created but still associates a single vnode with that device. Our current drivers rely on a hack to associate a separate vnode and store private state with each logical instance of a device. Device driver models under other operating systems have different ways for logical device instances to maintain private state. Linux associates a vnode with each opened instance of a device file, and Solaris keeps private per-instance state via DDI [1].