Add a proper device interface #18
Labels
arch: none
Not architecture specific
target: kernel
Kernel related features
type: new
Implement a new feature
Comments
d4ilyrun
added
target: kernel
3 tasks
d4ilyrun
added a commit
that referenced
this issue
Jun 13, 2024
Hardware device detection As described in #18, we want to be able to automatically detect all connected hardware devices before initializing them. To do so, we have at our disposition the ACPI standard. ACPI (Advanced Configuration and Power Interface) is a Power Management and configuration standard for the PC. Among other things, this standard lets us check for the presence of connected devices through information tables and an runtime environment provided by the BIOS. This merge request integrates into our kernel the uACPI library, which does all the heavylifting of parsing/editing these tables for us. Some of the necessary functionalities are not yet implemented inside our kernel, so the current implmentation of uACPI's public API hooks sometimes relies on stubs. Nevertheless, we can now succesfully list all the connected devices (minus those connected through PCI). Here's a list of what should be fixed/implemented: * Semaphore/Mutex * PCI I/O * Thread completion Closes #19 Signed-off-by: Léo DUBOIN <leo@duboin.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Devices
Everything, from the mouse to the network controller, is a device, and implementing a generic interface to easily declare and interact with these device is one of the most crucial part of the kernel. Ideally a the higher level APIs should not have to care about which device they are communicating with, nor should it impact their result.
Goals
What I want from this interface is:
Current state
Together with #17, we added a stub device interface.
It represents a contiguous array of memory (since this is the only thing we interact with as of now), and a basic read/write wrapper around a memcpy.
PoC
Once this interface is ready, it should be easily possible to treat #10. The console should simply write to the device representing the UART/Framebuffer, depending on the requested output device``
The text was updated successfully, but these errors were encountered: