FizzBuzz OS by mssola

Project Description

FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).

This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.

This project is free software and you can find it here.

Goal for this Hackweek

• Better understand the RISC-V SBI interface.
• Better understand RISC-V in privileged mode.
• Have fun.

Resources

• SBI v2.0 ratified specification
• Blog post on SBI
• mssola/fbos

Results

The project was a resounding success Lots of learning, and the initial target was met.

---

Add a machine-readable output to dmidecode by jdelvare

Description

There have been repeated requests for a machine-friendly dmidecode output over the last decade. During Hack Week 19, 5 years ago, I prepared the code to support alternative output formats, but didn't have the time to go further. Last year, Jiri Hnidek from Red Hat Linux posted a proof-of-concept implementation to add JSON output support. This is a fairly large pull request which needs to be carefully reviewed and tested.

Goals

Review Jiri's work and provide constructive feedback. Merge the code if acceptable. Evaluate the costs and benefits of using a library such as json-c.

---

FastFileCheck work by pstivanin

Description

FastFileCheck is a high-performance, multithreaded file integrity checker for Linux. Designed for speed and efficiency, it utilizes parallel processing and a lightweight database to quickly hash and verify large volumes of files, ensuring their integrity over time.

https://github.com/paolostivanin/FastFileCheck

Goals

• Release v1.0.0

Design overwiew:

• Main thread (producer): traverses directories and feeds the queue (one thread is more than enough for most use cases)
• Dedicated consumer thread: manages queue and distributes work to threadpool
• Worker threads: compute hashes in parallel

This separation of concerns is efficient because:

• Directory traversal is I/O bound and works well in a single thread
• Queue management is centralized, preventing race conditions
• Hash computation is CPU-intensive and properly parallelized

---

ESETv2 Emulator / interpreter by m.crivellari

Description

ESETv2 is an intriguing challenge developed by ESET, available on their website under the "Challenge" menu. The challenge involves an "assembly-like" language and a Python compiler that generates .evm binary files.

This is an example using one of their samples (it prints N Fibonacci numbers):

.dataSize 0
.code

loadConst 0, r1 # first
loadConst 1, r2 # second

loadConst 1, r14 # loop helper

consoleRead r3

loop:
    jumpEqual end, r3, r15

    add r1, r2, r4
    mov r2, r1
    mov r4, r2

    consoleWrite r1

    sub r3, r14, r3
    jump loop
end:
hlt

This language also supports multi-threading. It includes instructions such as createThread to start a new thread, joinThread to wait until a thread completes, and lock/unlock to facilitate synchronization between threads.

Goals

• create a full interpreter able to run all the available samples provided by ESET.
• improve / optimize memory (eg. using bitfields where needed as well as avoid unnecessary memory allocations)

Resources

• Challenge URL: https://join.eset.com/en/challenges/core-software-engineer
• My github project: https://github.com/DispatchCode/eset_vm2 (not 100% complete)

Achivements

Project still not complete. Added lock / unlock instruction implementation but further debug is needed; there is a bug somewhere. Actually the code it works for almost all the examples in the samples folder. 1 of them is not yet runnable (due to a missing "write" opcode implementation), another will cause the bug to show up; still not investigated, anyhow.

---