Merge branch 'fmorgner/develop-BA-FS26/pit-device' into develop-BA-FS26

This changeset introduces a central device management system. The system
comprises the following components:

- kapi::devices::bus (type)

  A bus can be both a real (physically present inside the machine) or
  virtual (purely conceptual) bus. Busses form a hierarchy rooted in the
  virtual root_bus (accessible via `kapi::devices::get_root_bus`).
  Busses are derived from `kapi::devices::device`, and own devices. This
  means that a bus can be attached to another bus. This facilitates a
  uniform structure for device ownership. Each device needs to be
  attached to exactly one bus. Virtual devices, e.g. RAM disks, should
  be attached to the root root bus (via the `add_child` member
  function).

  Once a device, or bus, has been attached to a bus, it will be
  initialized (by means of a call to the `init` member function). Busses
  are responsible to initialize their children. If a bus has already
  been initialized, any newly attached children will automatically be
  initialized.

  During initialization, the `probe` member function of the bus under
  initialization weill be invoked. This allows a bus implementation to
  determine if the hardware, if any, is ready to be initialized and to
  also perform any required initialization steps.

  IMPORTANT: busses take ownership of their children in the form of a
  `unique_ptr`.

- kapi::devices (namespace)

  The functions `allocate_major_number`, `register_device`,
  `unregister_device`, and `find_device` form the device manager.

  The device manager is responsible for keeping a record of active
  devices, allowing O(log n) lookup of devices by major and minor, and
  O(n) lookup by name. Additionally, the device manager is responsible
  for handing out major numbers (via `allocate_major_number`) and
  keeping track of active devices. When a child is attached to a bus, it
  will also automatically be registered with the device manager.

  Lookup of devices via the device manager can be achieved by means of
  either overload of `find_device`.

  Devices should never ask the manager directly for a major number.
  Instead, a controller should be used, which requests a major number
  per device "class" (as in kind, not language class). For example, a
  RAM disk controller may request a single major number for all RAM
  disks it is going to create. When the controller creates a new device
  of a given "class", e.g. a RAM disk, it should then supply that major
  number to the new device instance.

  IMPORTANT: the device manager does not own the active devices. Rather
  it holds a `flat_map` indexed by `pair{major, minor}` and resolving to
  `kstd::observer_ptr<device>`.

- kstd::observer_ptr (type)

  An observer pointer is a simple vocabulary type to express the concept
  of having no ownership of the pointed-to object. In essence it is
  equivalent to a standard C-style pointer, but expresses semantics by
  virtue of being a separate type.

0 files changed, 0 insertions, 0 deletions