system/serenity
system/serenity
1
0
Fork 0
mirror of https://github.com/SerenityOS/serenity synced 2024-07-23 02:55:15 +00:00
Code Issues Actions 4 Packages Projects Releases Wiki Activity
serenity/Kernel/Devices/DeviceManagement.h

80 lines
2.6 KiB
C
Raw Normal View History

Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
/*
* Copyright (c) 2021, Liav A. <liavalb@hotmail.co.il>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Badge.h>
Kernel: Replace KResult and KResultOr<T> with Error and ErrorOr<T> We now use AK::Error and AK::ErrorOr<T> in both kernel and userspace! This was a slightly tedious refactoring that took a long time, so it's not unlikely that some bugs crept in. Nevertheless, it does pass basic functionality testing, and it's just real nice to finally see the same pattern in all contexts. :^)
2021-11-07 23:51:39 +00:00
#include <AK/Error.h>
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
#include <AK/OwnPtr.h>
#include <AK/Types.h>
Kernel/Devices: Introduce the Device Control Device This device will assist userspace to manage hotplug events. A userspace application reads a DeviceEvent entry until the return value is zero which indicates no events that are queued and waiting for processing. Trying to read with a buffer smaller than sizeof(DeviceEvent) results in EOVERFLOW. For now, there's no ioctl mechanism for this device but in the future an acknowledgement mechanism can be implemented via ioctl(2) interface.
2021-12-20 09:10:35 +00:00
#include <Kernel/API/DeviceEvent.h>
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
#include <Kernel/API/TimePage.h>
Kernel: Add cross platform RegisterState header and Aarch64 version A new RegisterState header includes the platform specific RegisterState header based on the platform being compiled. The Aarch64 RegisterState header contains stubs for Debug
2021-10-14 22:01:29 +00:00
#include <Kernel/Arch/RegisterState.h>
Kernel: Teach DeviceManagement to handle multiple audio devices
2021-11-23 00:12:19 +00:00
#include <Kernel/Devices/CharacterDevice.h>
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
#include <Kernel/Devices/Device.h>
Kernel: Move a bunch of generic devices code into new subdirectory
2023-03-18 11:17:13 +00:00
#include <Kernel/Devices/Generic/ConsoleDevice.h>
#include <Kernel/Devices/Generic/DeviceControlDevice.h>
#include <Kernel/Devices/Generic/NullDevice.h>
Kernel: Make self-contained locking smart pointers their own classes Until now, our kernel has reimplemented a number of AK classes to provide automatic internal locking: - RefPtr - NonnullRefPtr - WeakPtr - Weakable This patch renames the Kernel classes so that they can coexist with the original AK classes: - RefPtr => LockRefPtr - NonnullRefPtr => NonnullLockRefPtr - WeakPtr => LockWeakPtr - Weakable => LockWeakable The goal here is to eventually get rid of the Lock* classes in favor of using external locking.
2022-08-19 18:53:40 +00:00
#include <Kernel/Library/LockRefPtr.h>
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
#include <Kernel/UnixTypes.h>
namespace Kernel {
class DeviceManagement {
public:
DeviceManagement();
static void initialize();
static DeviceManagement& the();
void attach_null_device(NullDevice const&);
Kernel/Devices: Introduce the Device Control Device This device will assist userspace to manage hotplug events. A userspace application reads a DeviceEvent entry until the return value is zero which indicates no events that are queued and waiting for processing. Trying to read with a buffer smaller than sizeof(DeviceEvent) results in EOVERFLOW. For now, there's no ioctl mechanism for this device but in the future an acknowledgement mechanism can be implemented via ioctl(2) interface.
2021-12-20 09:10:35 +00:00
void attach_device_control_device(DeviceControlDevice const&);
Kernel/Devices: Use try_create_device helper for ConsoleDevice
2021-09-16 19:23:25 +00:00
bool is_console_device_attached() const { return !m_console_device.is_null(); }
void attach_console_device(ConsoleDevice const&);
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
void after_inserting_device(Badge<Device>, Device&);
void before_device_removal(Badge<Device>, Device&);
void for_each(Function<void(Device&)>);
Kernel: Add DeviceManagement::try_for_each() for fallible iteration This API will allow users to short circuit iteration and properly propagate errors.
2022-02-24 18:03:26 +00:00
ErrorOr<void> try_for_each(Function<ErrorOr<void>(Device&)>);
Kernel: Get RefPtr<Device> from the DeviceManagement::get_device method Instead of returning a raw pointer, which could be technically invalid when using it in the caller function, we return a valid RefPtr of such device. This ensures that the code in DevPtsFS is now safe from a rare race condition in which the SlavePTY device is gone but we still have a pointer to it.
2024-03-04 19:19:31 +00:00
RefPtr<Device> get_device(MajorNumber major, MinorNumber minor);
Kernel/Devices: Use try_create_device helper for ConsoleDevice
2021-09-16 19:23:25 +00:00
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
NullDevice const& null_device() const;
NullDevice& null_device();
Kernel/Devices: Use try_create_device helper for ConsoleDevice
2021-09-16 19:23:25 +00:00
ConsoleDevice const& console_device() const;
ConsoleDevice& console_device();
Kernel: Add try_create_device overload for static factory functions This makes sure DeviceManagement::try_create_device will call the static factory function (if available) instead of directly calling the constructor, which will allow us to move OOM-fallible calls out of Device constructors.
2022-01-26 20:00:45 +00:00
template<typename DeviceType, typename... Args>
Everywhere: Run clang-format
2022-10-16 22:06:11 +00:00
static inline ErrorOr<NonnullLockRefPtr<DeviceType>> try_create_device(Args&&... args)
requires(requires(Args... args) { DeviceType::try_create(args...); })
Kernel: Add try_create_device overload for static factory functions This makes sure DeviceManagement::try_create_device will call the static factory function (if available) instead of directly calling the constructor, which will allow us to move OOM-fallible calls out of Device constructors.
2022-01-26 20:00:45 +00:00
{
auto device = TRY(DeviceType::try_create(forward<Args>(args)...));
Kernel: Make Device::after_inserting to return ErrorOr<void> Instead of just returning nothing, let's return Error or nothing. This would help later on with error propagation in case of failure during this method. This also makes us more paranoid about failure in this method, so when initializing a DisplayConnector we safely tear down the internal members of the object. This applies the same for a StorageDevice object, but its after_inserting method is much smaller compared to the DisplayConnector overriden method.
2022-12-21 20:33:56 +00:00
TRY(device->after_inserting());
Kernel: Add try_create_device overload for static factory functions This makes sure DeviceManagement::try_create_device will call the static factory function (if available) instead of directly calling the constructor, which will allow us to move OOM-fallible calls out of Device constructors.
2022-01-26 20:00:45 +00:00
return device;
}
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
template<typename DeviceType, typename... Args>
Kernel: Make self-contained locking smart pointers their own classes Until now, our kernel has reimplemented a number of AK classes to provide automatic internal locking: - RefPtr - NonnullRefPtr - WeakPtr - Weakable This patch renames the Kernel classes so that they can coexist with the original AK classes: - RefPtr => LockRefPtr - NonnullRefPtr => NonnullLockRefPtr - WeakPtr => LockWeakPtr - Weakable => LockWeakable The goal here is to eventually get rid of the Lock* classes in favor of using external locking.
2022-08-19 18:53:40 +00:00
static inline ErrorOr<NonnullLockRefPtr<DeviceType>> try_create_device(Args&&... args)
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
{
Kernel: Make self-contained locking smart pointers their own classes Until now, our kernel has reimplemented a number of AK classes to provide automatic internal locking: - RefPtr - NonnullRefPtr - WeakPtr - Weakable This patch renames the Kernel classes so that they can coexist with the original AK classes: - RefPtr => LockRefPtr - NonnullRefPtr => NonnullLockRefPtr - WeakPtr => LockWeakPtr - Weakable => LockWeakable The goal here is to eventually get rid of the Lock* classes in favor of using external locking.
2022-08-19 18:53:40 +00:00
auto device = TRY(adopt_nonnull_lock_ref_or_enomem(new (nothrow) DeviceType(forward<Args>(args)...)));
Kernel: Make Device::after_inserting to return ErrorOr<void> Instead of just returning nothing, let's return Error or nothing. This would help later on with error propagation in case of failure during this method. This also makes us more paranoid about failure in this method, so when initializing a DisplayConnector we safely tear down the internal members of the object. This applies the same for a StorageDevice object, but its after_inserting method is much smaller compared to the DisplayConnector overriden method.
2022-12-21 20:33:56 +00:00
TRY(device->after_inserting());
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
return device;
}
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-04-29 18:17:20 +00:00
SpinlockProtected<CircularQueue<DeviceEvent, 100>, LockRank::None>& event_queue(Badge<DeviceControlDevice>);
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
private:
Kernel: Make self-contained locking smart pointers their own classes Until now, our kernel has reimplemented a number of AK classes to provide automatic internal locking: - RefPtr - NonnullRefPtr - WeakPtr - Weakable This patch renames the Kernel classes so that they can coexist with the original AK classes: - RefPtr => LockRefPtr - NonnullRefPtr => NonnullLockRefPtr - WeakPtr => LockWeakPtr - Weakable => LockWeakable The goal here is to eventually get rid of the Lock* classes in favor of using external locking.
2022-08-19 18:53:40 +00:00
LockRefPtr<NullDevice> m_null_device;
LockRefPtr<ConsoleDevice> m_console_device;
LockRefPtr<DeviceControlDevice> m_device_control_device;
Kernel: Turn lock ranks into template parameters This step would ideally not have been necessary (increases amount of refactoring and templates necessary, which in turn increases build times), but it gives us a couple of nice properties: - SpinlockProtected inside Singleton (a very common combination) can now obtain any lock rank just via the template parameter. It was not previously possible to do this with SingletonInstanceCreator magic. - SpinlockProtected's lock rank is now mandatory; this is the majority of cases and allows us to see where we're still missing proper ranks. - The type already informs us what lock rank a lock has, which aids code readability and (possibly, if gdb cooperates) lock mismatch debugging. - The rank of a lock can no longer be dynamic, which is not something we wanted in the first place (or made use of). Locks randomly changing their rank sounds like a disaster waiting to happen. - In some places, we might be able to statically check that locks are taken in the right order (with the right lock rank checking implementation) as rank information is fully statically known. This refactoring even more exposes the fact that Mutex has no lock rank capabilites, which is not fixed here.
2022-11-09 10:39:58 +00:00
SpinlockProtected<HashMap<u64, Device*>, LockRank::None> m_devices {};
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-04-29 18:17:20 +00:00
SpinlockProtected<CircularQueue<DeviceEvent, 100>, LockRank::None> m_event_queue {};
Kernel: Introduce the DeviceManagement singleton This singleton simplifies many aspects that we struggled with before: 1. There's no need to make derived classes of Device expose the constructor as public anymore. The singleton is a friend of them, so he can call the constructor. This solves the issue with try_create_device helper neatly, hopefully for good. 2. Getting a reference of the NullDevice is now being done from this singleton, which means that NullDevice no longer needs to use its own singleton, and we can apply the try_create_device helper on it too :) 3. We can now defer registration completely after the Device constructor which means the Device constructor is merely assigning the major and minor numbers of the Device, and the try_create_device helper ensures it calls the after_inserting method immediately after construction. This creates a great opportunity to make registration more OOM-safe.
2021-09-11 06:19:20 +00:00
};
}
Reference in a new issue Copy permalink