Re: My free and open-source hobby operating system
I'm back with some major updates to the OS thus far, with, perhaps, some small performance increases here and there.
General
The disk I'm using has been recreated. Using NBD (network block device) technology of the Linux kernel, I was able to mount this QCOW2 disk on /dev/nbd0 and format it as GPT with EXT2. Since EXT2 is ridiculously slow at formatting the disk, the disks size is quite small (though that is also because of git hubs file size limitations). It will be enough for our purposes for now however.
I've increased the overall memory requirement of the emulation to 1 GB of RAM. Though I could go much (much) higher, my kernel has yet to require that much RAM yet. Hell, it could operate under 16 MB of RAM just fine.
Code quality
Last week I ran clippy on the entire project and have gone through and fixed about 99 percent of its warnings. I have also turned on nearly every lint that the Rust compiler has and set it to 'deny', pretty much forcing myself and contributors to use higher code quality in general. This way, its really obvious when someone contributes something and they use #[allow()] to get around a lint. Originally I wanted to set this to 'forbid', which prevents people from overriding the lints, but the macros my kernel uses (i.e. lazy_static!) caused compilation errors, so I'm stuck with deny for now.
Core: interrupts
The RTC timer now uses a reader-writer lock instead of a full mutex lock. For those wh odo't know, a reader-writer lock allows unlimited readers to read the data that the lock is protecting, but to write to it exclusive acquisition is needed. A full mutex lock, on the other hand, requires a caller to gain exclusive access to the lock to read or write to it, which I believe was making my code a lot slower than it could be. To compensate for the reader-writer issues, I have modified the get_tick_count() function and the RTC timer interrupt to attempt to acquire the lock. If the RTC timer interrupt is unable to acquire the lock, it never increments the value held within. Since this interrupt is called every 122 US, there's currently over a 70 percent chance it will acquire it within a few ticks, if even less. The get_tick_count() function returns 0 if it can't acquire a reader lock when it is called. This will not affect sleeping, since the value will appear to never have changed.
Core: PCI
The PCI subsystem now uses a linked list instead of a Vec. While both of these allocate memory, the LinkedList structure only allocates memory when an item is added to the list and not when it is created, saving a (potentially) costly memory allocation until it is actually needed. This also creates a performance boost in the PCI enumeration code since adding elements to the list should always occur in O(1) time unless there are other outstanding circumstances.
The PCI interface device scanning functions for drivers has been changed. New contributors, when writing drivers, should use pci::find_device() or pci::find_device_x() to locate a device instead of iterating through all devices. The function for retrieving a list of all devices has also been removed, though it may be re-added later. The pci::find_device() function takes a class, subclass, and program interface, and returns an Option<PCIDevice>, and pci::find_device_x() takes a class, subclass, an array of vendor codes, and an array of device IDs and returns an Option<PCIDevice>. Both functions are always inlined.
Core: memory manager
Error checking has been added to those functions that did not have them but that called unwrap() anyway.
The kernel is now assigned an 8 MB heap, though this is probably overkill and the performance cost is definitely noticeable.
Driver updates
Keyboard driver
The keyboard driver now uses 4 statically allocated buffers instead of dynamically allocating memory for every key event. Each buffer contains 512 Option<> items. If the buffer is full, new keys that are received are dropped on the floor. This will make actual UIs difficult to write since the keyboard driver does not (yet) follow the Reader-Writer lock paradigm like the RTC timer does, though I will be updating that sometime soon. However, the remaining changes will make the driver much easier to use when called upon.
The driver has been pretty much entirely rewritten to use functional elements instead of handwritten, untested code. During the rewrite I did my est to take advantage of all of Rusts functional capabilities instead of trying to handcraft my own. As an example, instead of a match statement on practically every other line,causing overall messiness, the driver uses functions like zip(), iter_mut() and so on.
The keyboard driver now exposes two "truly public" functions, read_key() and read_character(). This will make writing UIs a lot simpler since you do not receive a tuple of values like you did before and instead can filter based on the state of the system at the time you'd like input from the user. Both functions return an Option<>: read_character() returns an Option<char> and read_key() returns an Option<pc_keyboard::KeyCode>.
Intel HDA
The HDA driver now stores, statically, memory addresses for the Command Output Ring Buffer (CORB) and Response Input Ring Buffer (RIRB), which it also dynamically configures and sets to random memory addresses. It is now fully capable of transmitting commands to the controller and receiving responses from it. Currently it still beaks (though I am attempting to determine, with the OSDev community's help, whether it is just Qemu being faulty or whether my code is actually broken.
AHCI
The AHCI driver has been unlinked from the execution chain for now since it is broken. It is still built but it is never initialized.
ATA
An ATA driver has been added. ATA is the precursor to AHCI, only allowing 4 disks instead of up to 32, but both are very interconnected and closely related. The ATA driver uses port IO instead of DMA, which causes a slight performance degradation; however, this performance cost is payable for now and allows us to move onto greater and better things. This ATA driver is able to send commands to the ATA controller and receive responses from it, and is also able to read sectors from the disk. This has, for example, allowed me to determine the number of sectors that the disk has, as well as find the GPT partition table header signature. The module is divided into five separate submodules, most of which are unused/still in development as of commit E6AED9F:
The main module contains ATA commands as defined in INCITS 452-2009 (R 2019). All of these commands are marked as 'unsafe' since port IO is used and sending values incorrectly to the controller could cause undefined behavior. Commands that have "safe" equivalents (i.e. commands that build data structures for easier handling and such) have the suffix '_raw' added to them, indicating that, when called, they will return raw data instead of doing anything useful with it. The caller will then need to interpret the returned data themselves.
The 'identification' submodule contains data structures for the Identify Device command. Identify Device returns 256 words (16-bit values) that contain device characteristics, capabilities, etc. See 7.16 of ATA8 ACS, INCITS 452-2009 (R 2019) for more information on what each word contains. Though they are incomplete, the data structures in the identification module itself may be of use in understanding the Identify Device command as well.
The "security", "smart", and "dco" submodules are currently excluded from the build; when complete, they will include functions for accessing and manipulating the security feature set, the SMART feature set, and the device configuration overlay (DCO).
GPT
A GPT driver has been started to begin the process of parsing the data at LBA 1 on the disk. LBA 1 contains the GPT partition table header, and LBAs 2-33 contain partition table entries. Once the GPT driver is complete, the ATA driver will most likely also be complete, makign it possible to read and write data on the disk (this also includes compact flash media if supported using the media card passthrough feature set). This will also begin building the chain of modules required to read and write data within filesystems so that we can complete the virtual filesystem layer. Once the VFS has complete and we are able to read at least one filesystem, even minimally, we can begin on making it possible to load kernel modules from the filesystem to allow the kernel to be extended.
That's all the changes I've done thus far. Audio still doesn't work (unless you like the PC speaker that is) though I think I'm getting somewhere! If anyone is willing to take the plunge into low-level code, I strongly encourage anyone who would like to help to dive in and go! If you'd like to contribute, the best way of contacting me would either be via email/PM, or by contacting me on TT. I'm not on Skype as much any more, though that is another way of contacting me.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
