<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pub/teachos/kernel.git, branch feature/readBootSector</title>
<subtitle>An educational OS kernel</subtitle>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/'/>
<entry>
<title>kernel/filesystems: add tests for probe and better NOLINT comments</title>
<updated>2026-10-11T07:38:00+00:00</updated>
<author>
<name>manuel</name>
<email>manuel.bott@eps.ch</email>
</author>
<published>2026-10-11T07:38:00+00:00</published>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/commit/?id=2d7acbf819aa1377c240c874539151001a5f96ce'/>
<id>2d7acbf819aa1377c240c874539151001a5f96ce</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>kernel/filesystems: read entire boot sector fat32 and print</title>
<updated>2026-10-08T08:30:26+00:00</updated>
<author>
<name>manuel</name>
<email>manuel.bott@eps.ch</email>
</author>
<published>2026-10-08T08:30:26+00:00</published>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/commit/?id=a92f378780c457ae8120ef66e33ebed0169975ec'/>
<id>a92f378780c457ae8120ef66e33ebed0169975ec</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>added fat32 img, wip parse bootsector</title>
<updated>2026-10-05T12:47:32+00:00</updated>
<author>
<name>bbuerge</name>
<email>b.buerge@proton.me</email>
</author>
<published>2026-10-05T12:47:32+00:00</published>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/commit/?id=007696a98d84ae74ac95dc66c23c8770d6bff065'/>
<id>007696a98d84ae74ac95dc66c23c8770d6bff065</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'fa26/copy-and-rename-rootfs-to-fat32' into 'fa26/develop'</title>
<updated>2026-09-29T05:38:07+00:00</updated>
<author>
<name>Benjamin Bürge</name>
<email>benjamin.buerge@ost.ch</email>
</author>
<published>2026-09-29T05:38:07+00:00</published>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/commit/?id=4f634ec5bf412954eff23e8410ae8f21264b6793'/>
<id>4f634ec5bf412954eff23e8410ae8f21264b6793</id>
<content type='text'>
kernel/filesystems: copy and rename rootfs to fat32

See merge request teachos/kernel!60</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
kernel/filesystems: copy and rename rootfs to fat32

See merge request teachos/kernel!60</pre>
</div>
</content>
</entry>
<entry>
<title>kernel/filesystems: rename test to fix test error</title>
<updated>2026-09-28T07:01:18+00:00</updated>
<author>
<name>manuel</name>
<email>manuel.bott@eps.ch</email>
</author>
<published>2026-09-28T07:01:18+00:00</published>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/commit/?id=748d47cdadcc2bc292bfe5bbde68114cad0b3adb'/>
<id>748d47cdadcc2bc292bfe5bbde68114cad0b3adb</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>kernel/filesystems: copy and rename rootfs to fat32</title>
<updated>2026-09-24T08:07:19+00:00</updated>
<author>
<name>manuel</name>
<email>manuel.bott@eps.ch</email>
</author>
<published>2026-09-24T08:07:19+00:00</published>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/commit/?id=59c2e1cfa42ce030ae7c78ed39391c1c57faedda'/>
<id>59c2e1cfa42ce030ae7c78ed39391c1c57faedda</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>build/x86_64: add missing -ffreestanding flag</title>
<updated>2026-09-17T12:17:22+00:00</updated>
<author>
<name>Felix Morgner</name>
<email>felix.morgner@ost.ch</email>
</author>
<published>2026-09-17T12:17:22+00:00</published>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/commit/?id=5bad38935238da045d9fd467eae9dfd958deea34'/>
<id>5bad38935238da045d9fd467eae9dfd958deea34</id>
<content type='text'>
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 &lt; n: ++i)
  {
    d[i] = static_cast&lt;std::byte&gt;(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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt; n: ++i)
  {
    d[i] = static_cast&lt;std::byte&gt;(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.
</pre>
</div>
</content>
</entry>
<entry>
<title>ide: silence LTRANS job server warning</title>
<updated>2026-09-14T10:35:50+00:00</updated>
<author>
<name>Felix Morgner</name>
<email>felix.morgner@ost.ch</email>
</author>
<published>2026-09-14T10:35:50+00:00</published>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/commit/?id=bc31452b02c938ab522ace77f3da99f70c087f3b'/>
<id>bc31452b02c938ab522ace77f3da99f70c087f3b</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>kstd: fix doc comment</title>
<updated>2026-09-10T14:46:51+00:00</updated>
<author>
<name>Felix Morgner</name>
<email>felix.morgner@ost.ch</email>
</author>
<published>2026-09-10T14:46:51+00:00</published>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/commit/?id=7c299dab6436c3ee1ed2cf5154c8b20a92d23cd9'/>
<id>7c299dab6436c3ee1ed2cf5154c8b20a92d23cd9</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>kapi/system: reduce panic buffer size</title>
<updated>2026-09-10T14:38:41+00:00</updated>
<author>
<name>Felix Morgner</name>
<email>felix.morgner@ost.ch</email>
</author>
<published>2026-09-10T14:38:41+00:00</published>
<link rel='alternate' type='text/html' href='http://source.arknet.ch/pub/teachos/kernel.git/commit/?id=c63a0f8e7ed7a2d88cb24a46a6fd8e409f35756b'/>
<id>c63a0f8e7ed7a2d88cb24a46a6fd8e409f35756b</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
</feed>
