Request tagging

In Eclipse/BSD, every request arriving at a scheduler must be tagged with the queue used for that request, as explained in this section.

Resource reservations often cannot simply be associated with shared objects because different clients' requests may specify the same object but different queues. For example, two processes may be in different reservation domains and each need to use a different disk queue to access a shared file, or a different network output link queue to send packets over a shared socket. It would be difficult to compound reservations used on the same object correctly if reservations were associated with the object, since then one client could benefit from another client's reservations.

Therefore, Eclipse/BSD queues are associated with references to shared objects, rather than the shared objects themselves (e.g., process, memory object, vnode, or socket). This is accomplished by modifying FreeBSD data structures as follows:

• The CPU scheduler manages activations instead of processes. An activation points to a process and to the CPU queue in which that process should run.
• The memory region structure points to the region's memory object and memory queue.
• The file descriptor structure points to the file (and thereby to the vnode or socket) and to the device queue used for I/O on that file descriptor.

CPU, memory, and device queue pointers are always initialized to the process's default queue for the respective resource. Queue pointers can subsequently be modified only to descendents of the process's root reservation for the respective resource. Initialization and modification of queue pointers occur as follows:

• The initial activation created when a process P is spawned has CPU queue pointer according to the crdom file of P's parent. P can subsequently create children of its CPU root reservation, e.g. to process each client's requests. P can switch directly from one CPU queue to another by using a new system call, activation_switch. Alternatively, P can spawn new processes that run on CPU queues according to P's crdom file.
• The memory queue pointer of a region R is initialized when R is allocated, and can subsequently be modified using a new system call, mreserv, with region address, length, and name of the new memory queue as arguments.
• The device queue pointer of a file descriptor fd is initialized: for vnodes, at open time; for connected sockets, at connect or accept time; for unconnected sockets, at sendto or sendmsg time if fd's device queue pointer has not yet been initialized. A new command to the fcntl system call, F_QUEUE_GET, returns the name of the queue to which fd currently points. The queue pointer can subsequently be modified using the new command F_QUEUE_SET to the fcntl system call, with the name of the new device queue as argument.

Additionally, I/O request data structures (including uio for all I/O, mbuf for all network output, and buf for disk input that misses in the buffer cache and for all disk output) gain a pointer to the queue they use. Eclipse/BSD copies a file descriptor's queue pointer to the I/O requests generated using that file descriptor.