Kernel Support Library

Description

The intent of this library is to provide tooling runtime support to kernel mode libaries, PAL, PRLs, and possibly even the kernel itself.

Rationale

The PRL interface was designed to work with a pair of platform resources; one for critical data, e.g., DMA buffers, the other resource is for a "bag of bytes" of data, at least from the perspective of the PRL. In network terminology the terms for these aspects of the problem are called, respectively, the control and data domains/planes.

There has never been any runtime support for this design, so each PRL has had to invent its own implementation.

Tooling

Stuff for config tools, e.g., support for creating pairs of platform resources and other stuff. All TBD.

Runtime

There will be a kernel-mode library, name TBD providing PPIs. The intent is that the PPI symbols will somehow ensure they are not accidentally used by user mode. E.g., memcpy_PPI rather than memcpy, or some other TBD mechanism.

Supported APIs

Envisioned interfaces:

1. subset of ANSI, e.g., string operations, strcmp() and friends; memset() memcpy(), etc.
2. Atomics
3. Generally useful parameter verification functions, e.g., "is this 64-bit range contained within some other 64-bit range", etc.
4. Safe copy data from data plane buffer into control plane buffer.
   1. Useful in situations where there is more data to send to the PRL than can be done by callPlatformResourceFunction().
   2. Ensure control plane buffer is appropriately acquired, locked, and memory is cross core consistent.
5. Support for managing control and data plane platform resources
   1. linked list services
6. allocate and deallocate buffer pairs from a pair of platform resources.

   Suggest implementation strategy:

   1. Treat control and data plane platform resources as an array of buffers.
   2. Treat control and data plane buffers as a pair.
   3. Construct routine to atomically allocate/deallocate an index.
   4. Some support for controlling the state of a control plane buffer.
      1. Likely tri-state: Free, in use by PRL, in use by HW. Very preliminary.
      2. There will need to be some mechanism to recover buffers that are lost because a user mode code failed to return a buffer, e.g., due to design flaw, exception occurred, ill-timed thread restart, etc.
         1. If the mechanism is invoked as part of a process startup, then a restart process would automatically recover such buffers.

With a level of indirection it would be possible to support different sized data plane buffers.

Environment

A driver utilizing a PRL will likely (always?) have the following memory resources that it will have to read, and (perhaps) write:

1. PS-UW: A process specific user writable platform resource.
   • E.g., for data to be sent to the device.
2. PS-KM: A process specific kernel-mode (not user writable) platform resource.
   • E.g., for DMA buffer descriptors
3. DR: A kernel-mode resource for the device registers
   • The "attachment" may be due to a process specific attachPlatformResource(), or via the PRL registration function.
4. SP A support process that is the home of ISR threads and other common administrivia.
   • E.g., the lwip process which maintains "global" stuff like routing tables, etc.

A process specific driver would likely need access to all 4 of the memory regions. All accesses would have to address multi-thread and multi-core issues.

Hopefully hardware support would enable, for example, a process to program a classifier so that it is the destination for all data sent to a specific PORT. This way the latency to get data would not be driven by the SP and its ISR threads.

Any access to the SP would have to account for all sorts of stuff, and how and/or whether writes should be permitted is TBD.

The device driver would have to handle interesting process transitions:

1. Startup.
2. Thread/process restart
3. User mode not following protocols, e.g., acquiring a driver resource and never returning it.
4. Process deletion
5. Deos Warmstart/Coldstart

Status

Dreams and talk.

Goals

Fame and fortune.