Commit graph

6 commits

Author SHA1 Message Date
Space Meyer
106d4636a4 Revert "Kernel+SystemServer: Make KCOVDevice a character device"
This reverts commit 9dbec601b0.

For KCOV to be performant (or at least not even slower) we need to
mmap the PC buffer from both user and kernel space at the same time.
You can't mmap a character device, so this change didn't make sense.

Plus even if we did invent a new method to exfiltrate the coverage
information out of the kernel, it would be incompatible with existing
kernel fuzzers. That would be kind of annoying. 🙃
2024-04-15 21:16:22 -06:00
Shannon Booth
6ce0d588ee Everywhere: Avoid calling from_utf8 on FlyString or String
We already have a String :^)
2023-12-10 09:45:03 +01:00
Liav A
1b00618fd9 Kernel+Userland: Replace the beep syscall with the new /dev/beep device
There's no need to have separate syscall for this kind of functionality,
as we can just have a device node in /dev, called "beep", that allows
writing tone generation packets to emulate the same behavior.

In addition to that, we remove LibC sysbeep function, as this function
was never being used by any C program nor it was standardized in any
way.
Instead, we move the userspace implementation to LibCore.
2023-11-03 15:19:33 +01:00
Liav A
ac70abcb73 DeviceMapper: Add a mechanism to handle pluggable-once char devices 2023-11-03 15:19:33 +01:00
Tim Ledbetter
c74f7e5f2a Userland: Don't use String::from_utf8() for literal strings 2023-09-15 08:44:52 +02:00
Liav A
446200d6f3 Kernel+Services: Enable barebones hot-plug handling capabilities
Userspace initially didn't have any sort of mechanism to handle
device hotplug (either removing or inserting a device).
This meant that after a short term of scanning all known devices, by
fetching device events (DeviceEvent packets) from /dev/devctl, we
basically never try to read it again after SystemServer initialization
code.

To accommodate hotplug needs, we change SystemServer by ensuring it will
generate a known set of device nodes at their location during the its
main initialization code. This includes devices like /dev/mem, /dev/zero
and /dev/full, etc.

The actual responsible userspace program to handle hotplug events is a
new userspace program called DeviceMapper, with following key points:
- Its current task is to to constantly read the /dev/devctl device node.
  Because we already created generic devices, we only handle devices
  that are dynamically-generated in nature, like storage devices, audio
  channels, etc.

- Since dynamically-generated device nodes could have an infinite minor
  numbers, but major numbers are decoded to a device type, we create an
  internal registry based on two structures - DeviceNodeFamily, and
  RegisteredDeviceNode. DeviceNodeFamily objects are attached in the
  main logic code, when handling a DeviceEvent device insertion packet.
  A DeviceNodeFamily object has an internal HashTable to hold objects of
  RegisteredDeviceNode class.

- Because some device nodes could still share the same major number (TTY
  and serial TTY devices), we have two modes of allocation - limited
  allocation (so a range is defined for a major number), or infinite
  range. Therefore, two (or more) separate DeviceNodeFamily objects can
  can exist albeit sharing the same major number, but they are required
  to allocate from a different minor numbers' range to ensure there are
  no collisions.

- As for KCOV, we handle this device differently. In case the user
  compiled the kernel with such support - this happens to be a singular
  device node that we usually don't need, so it's dynamically-generated
  too, and because it has only one instance, we don't register it in our
  internal registry to not make it complicated needlessly.

The Kernel code is modified to allow proper blocking in case of no
events in the DeviceControlDevice class, because otherwise we will need
to poll periodically the device to check if a new event is available,
which would waste CPU time for no good reason.
2023-09-07 11:50:50 -06:00