serenity - The Serenity Operating System 🐞

Age	Commit message (Collapse)	Author
2020-05-08	Kernel: Use NonnullRefPtrVector for HardwareTimer and HPETComparator	Andreas Kling

2020-04-18	Kernel: Remove CommandLine::get() in favor of lookup()	Andreas Kling
	lookup() returns an Optional<String> which allows us to implement easy default values using lookup(key).value_or(default_value);
2020-04-16	Kernel: Rename HardwareTimer::change_function() => set_callback()	Andreas Kling
	Also make it non-virtual since nothing needs to override it.
2020-04-16	Kernel: Remove "stale callback" concept from time management	Andreas Kling
	If a hardware timer doesn't have a callback registered, it's now simply represented by a null m_callback.
2020-04-16	Kernel: Remove an unnecessary indirection between timer and scheduler	Andreas Kling
	We don't need a wrapper Function object that just forwards the timer callback to the scheduler tick function. It already has the same signature, so we can just plug it in directly. :^) Same with the clock updating function.
2020-04-16	Kernel: Simplify the way we pass HardwareTimers around a bit	Andreas Kling
	Instead of passing around indices into the m_hardware_timers vector, just pass around a HardwareTimer* instead.
2020-04-09	Kernel: Simplify the Time management initialization	Liav A

2020-04-09	Kernel: Remove redundant "ACPI" from filenames in ACPI/	Andreas Kling

2020-04-09	Kernel: Remove "non-operational" ACPI parser state	Andreas Kling
	If we don't support ACPI, just don't instantiate an ACPI parser. This is way less confusing than having a special parser class whose only purpose is to do nothing. We now search for the RSDP in ACPI::initialize() instead of letting the parser constructor do it. This allows us to defer the decision to create a parser until we're sure we can make a useful one.
2020-04-08	Kernel: Rename KParams => Kernel::CommandLine	Andreas Kling
	Let's make this read more like English.
2020-03-19	Kernel: Introduce the new Time management subsystem	Liav A
	This new subsystem includes better abstractions of how time will be handled in the OS. We take advantage of the existing RTC timer to aid in keeping time synchronized. This is standing in contrast to how we handled time-keeping in the kernel, where the PIT was responsible for that function in addition to update the scheduler about ticks. With that new advantage, we can easily change the ticking dynamically and still keep the time synchronized. In the process context, we no longer use a fixed declaration of TICKS_PER_SECOND, but we call the TimeManagement singleton class to provide us the right value. This allows us to use dynamic ticking in the future, a feature known as tickless kernel. The scheduler no longer does by himself the calculation of real time (Unix time), and just calls the TimeManagment singleton class to provide the value. Also, we can use 2 new boot arguments: - the "time" boot argument accpets either the value "modern", or "legacy". If "modern" is specified, the time management subsystem will try to setup HPET. Otherwise, for "legacy" value, the time subsystem will revert to use the PIT & RTC, leaving HPET disabled. If this boot argument is not specified, the default pattern is to try to setup HPET. - the "hpet" boot argumet accepts either the value "periodic" or "nonperiodic". If "periodic" is specified, the HPET will scan for periodic timers, and will assert if none are found. If only one is found, that timer will be assigned for the time-keeping task. If more than one is found, both time-keeping task & scheduler-ticking task will be assigned to periodic timers. If this boot argument is not specified, the default pattern is to try to scan for HPET periodic timers. This boot argument has no effect if HPET is disabled. In hardware context, PIT & RealTimeClock classes are merely inheriting from the HardwareTimer class, and they allow to use the old i8254 (PIT) and RTC devices, managing them via IO ports. By default, the RTC will be programmed to a frequency of 1024Hz. The PIT will be programmed to a frequency close to 1000Hz. About HPET, depending if we need to scan for periodic timers or not, we try to set a frequency close to 1000Hz for the time-keeping timer and scheduler-ticking timer. Also, if possible, we try to enable the Legacy replacement feature of the HPET. This feature if exists, instructs the chipset to disconnect both i8254 (PIT) and RTC. This behavior is observable on QEMU, and was verified against the source code: https://github.com/qemu/qemu/commit/ce967e2f33861b0e17753f97fa4527b5943c94b6 The HPETComparator class is inheriting from HardwareTimer class, and is responsible for an individual HPET comparator, which is essentially a timer. Therefore, it needs to call the singleton HPET class to perform HPET-related operations. The new abstraction of Hardware timers brings an opportunity of more new features in the foreseeable future. For example, we can change the callback function of each hardware timer, thus it makes it possible to swap missions between hardware timers, or to allow to use a hardware timer for other temporary missions (e.g. calibrating the LAPIC timer, measuring the CPU frequency, etc).