| Age | Commit message (Collapse) | Author |
|---|
|
MemoryManager cannot use the Singleton class because
MemoryManager::initialize is called before the global constructors
are run. That caused the Singleton to be re-initialized, causing
it to create another MemoryManager instance.
Fixes #3226
|
|
This reverts commit f48feae0b2a300992479abf0b2ded85e45ac6045.
|
|
This reverts commit f0906250a181c831508a45434b9f645ff98f33e4.
|
|
This reverts commit 5a98e329d157a2db8379e0c97c6bdc1328027843.
|
|
Just default the InitFunction template argument.
|
|
|
|
Fixes #3226
|
|
|
|
This resolves a bochs panic during bootup:
[Kernel]: HPET @ P0x07ff0fc0
00691951632p[HPET ] >>PANIC<< Unsupported HPET read at address 0x0000fed00100
These changes however don't fully resolve #2162
|
|
This was supposed to be the foundation for some kind of pre-kernel
environment, but nobody is working on it right now, so let's move
everything back into the kernel and remove all the confusion.
|
|
Hide the implementation of time-of-day computation in TimeManagement.
|
|
|
|
|
|
lookup() returns an Optional<String> which allows us to implement easy
default values using lookup(key).value_or(default_value);
|
|
|
|
Also make it non-virtual since nothing needs to override it.
|
|
If a hardware timer doesn't have a callback registered, it's now simply
represented by a null m_callback.
|
|
|
|
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.
|
|
Instead of passing around indices into the m_hardware_timers vector,
just pass around a HardwareTimer* instead.
|
|
|
|
|
|
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.
|
|
Let's make this read more like English.
|
|
|
|
String.h no longer pulls in StringView.h. We do this by moving a bunch
of String functions out-of-line.
|
|
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).
|
