summaryrefslogtreecommitdiff
path: root/Kernel/Devices/DeviceManagement.cpp
AgeCommit message (Collapse)Author
2022-02-27Kernel: Add DeviceManagement::try_for_each() for fallible iterationIdan Horowitz
This API will allow users to short circuit iteration and properly propagate errors.
2022-02-14Kernel/Audio: Introduce a new design architecture for the subsystemLiav A
We have 3 new components: 1. The AudioManagement singleton. This class like in other subsystems, is responsible to find hardware audio controllers and keep a reference to them. 2. AudioController class - this class is the parent class for hardware controllers like the Sound Blaster 16 or Intel 82801AA (AC97). For now, this class has simple interface for getting and controlling sample rate of audio channels, as well a write interface for specific audio channel but not reading from it. One AudioController object might have multiple AudioChannel "child" objects to hold with reference counting. 3. AudioChannel class - this is based on the CharacterDevice class, and represents hardware PCM audio channel. It facilitates an ioctl interface which should be consistent across all supported hardware currently. It has a weak reference to a parent AudioController, and when trying to write to a channel, it redirects the data to the parent AudioController. Each audio channel device should be added into a new directory under the /dev filesystem called "audio".
2022-02-03Kernel: Protect global device map with spinlock instead of mutxAndreas Kling
2022-01-23Kernel/Devices: Introduce the Device Control DeviceLiav A
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-23Kernel: Make major and minor numbers to be DistinctNumericsLiav A
This helps avoid confusion in general, and make constructors, methods and code patterns much more clean and understandable.
2021-11-23Kernel: Teach DeviceManagement to handle multiple audio devicesJelle Raaijmakers
2021-09-17Kernel/Devices: Use try_create_device helper for SB16Liav A
2021-09-17Kernel/Devices: Use try_create_device helper for ConsoleDeviceLiav A
2021-09-17Kernel: Introduce the DeviceManagement singletonLiav A
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.