| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
kapi/interrupts: implement irq_lock
See merge request teachos/kernel!61
|
|
|
|
|
|
|
|
|
|
The previous implementation suffered from four problems:
1. try_lock in the basic irq_lock always succeeded.
2. lock in the basic irq_lock always succeeded.
3. try_lock in the wrapper irq_lock did not use the base try_lock.
4. a foreign CPU could wrongly unlock a remote irq_lock.
These issues are mitigated in this patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Enable the '-ffreestanding' flag in the x86_64 toolchain file to inform
the compiler about the fact that it cannot rely on the presence of a
standard library implementation, thereby suppressing some optimizations
designed for regular user applications.
GCC supports a number of clever optimizations, some of which rely on the
presence of a standard library. One of them is
"-ftree-loop-distribute-patterns". This optimization performs detection
of certain loop patterns, replacing them with library calls when
applicable. This is problematic for cases in which we implement the
standard library functionality. Consider, a schematic, `memset``:
```c++
void memset(void * d, int v, size_t n)
{
for(auto i = 0uz; i < n: ++i)
{
d[i] = static_cast<std::byte>(v);
}
}
```
GCC recognizes this loop, and similar versions of it, as an
implementation of `memset`. In a hosted implementation, this is an
important optimization, since a standard library may be able to provide
a specifically optimized version of `memset``. So the compiler replaces
this `memset` loop with a call to `memset`, since it is not aware of the
fact we are currently implementing `memset`. Interestingly, tail
recursion optimization eliminates the call, transforming it into a jump
to the start of `memset`. This leads to execution getting stuck inside
`memset` with no way of exiting and no stack usage increase, thus
causing an infinite lockup.
While we could suppress the specific optimization, it is more effective
to tell the compiler "why" it can emit a call to memset in those cases.
|
|
|
|
|
|
Previously, we allocated a 512-byte buffer for every call of the
formatted panic function. This was heavily increasing the stack size for
a number of functions.
We now don't print to a statically allocated buffer, but rather use the
iterator-based formatting facility and a proxy iterator with a small,
self-flushing buffer. This reduces that static overhead of the formatted
panic function to by almost 500 bytes, while increasing possible message
fidelity, since we are not longer arbitrarily limited by the buffer.
|
|
|
|
|
|
|
|
|
|
Previously, the number registry did a pruning pass whenever elements,
either all or a filtered subset, were queried by a consumer. This meant,
that every access to elements did an additional O(n) scan of the entire
registry, to ensure no expired devices were still registered. This used
to be necessary, when the ownership model for devices was still in flux.
With the established device ownership model, this has become obsolete.
Additionally, devices get numbered automatically when a device gains a
facet the is observed by the device number registry. Since registering
this type of facet is the responsibility of the device driver, since
only a driver can know how to implement that facet for any given device,
it also becomes the responsibility of the driver to revoke that facet
if and when a device is detached from the system. Any device is always
owned by the bus it is attached to. This means it is the bus'
responsibility to inform drivers about devices disappearing. This closes
the chain of responsibility cleanly, meaning the device number registry
will never have to prune itself in any accessors. Instead, it will be
informed by the facet registry that a facet for a device has been
revoked, allowing it to un-number that device if applicable.
|
|
|
|
|
|
|
|
|
|
|
|
x86_64: handle double faults
See merge request teachos/kernel!59
|
|
The coding guidelines explicitly prohibit the use of "naked"/C-style
pointers. However, there were some prominent examples in the kapi and
the core kernel source. This changeset replaces them with the
appropriate smart pointer types.
|
|
|
|
|
|
|
