Humble hobby OS project

Isoux said:
To be honest, I don’t feel ready to handle deep technical questions from professionals — at least not yet. Maybe this project still needs to mature a bit more, to show more stable functionality… and perhaps I need to mature along with it.
Click to expand...
Yes, you must surely be right, but it doesn't matter; do as you feel. Explaining to others is often very educational for oneself and allows one to better organize one's thoughts and sort out what one knows and what one thinks he knows.
 
Crivens said:
Nope. You can do real work with a series of casts, it is not just a "pretend" construct.
Example:
uint32_t i = get_some_number();
i = (uint32) (char) i;
Now i holds the sign extended 8 bit value it had before, loosing the upper bits.
i = (uint32) (uint8_t) i; is equivalent to "i &= 0x0ff;"
Click to expand...

Of course it's cool and tricky, but I would metaphorically smack anyone who did that up side the head, while yelling "bad engineer! no cookie!"

Actually, someone may come up with some esoteric need, but I'd more take offense to it if the construct wasn't immediately followed by an indented comment explains what that monstrosity does, and why it's needed.
 
doul said:
Some words about why OSes don't use the 4 rings.

https://superuser.com/questions/1063420/why-do-x86-cpus-only-use-2-out-of-4-rings ->"But there are not that many segment descriptors available."
Click to expand...
This is actually not true. The GDT can support up to 8192 segment descriptors, which is more than sufficient for a complex multi-ring setup.

In my implementation, I've allocated space for all 8192 descriptors in the GDT — not all are filled yet, of course — but I plan to use many of them for call gates, task gates, and other segmentation-based structures.

Segmentation combined with paging is still powerful, and I'm actively using both.

Even if this experiment doesn't fully succeed, it's already a success for me — simply because I chose to dive deep into these lesser-explored aspects of hardware.

At the very least, this project might serve as proof — whether for or against — claims often repeated by people who've never actually tried to push these mechanisms to their limits, but instead just quote theory.
 
That article presents the mainstream reasoning — that modern OSes only use two rings due to paging granularity and portability concerns. But my goal is quite the opposite.
  1. Non-portability is intentional, not a flaw
    Many OSes avoid segmentation to remain portable across architectures. I deliberately reject that approach. R4R is designed to be deeply tied to Intel x86, using every available hardware feature — segmentation, TSS, call gates, and all four rings — not for compatibility, but for exploration and understanding of what the hardware can truly do.
  2. Paging limitations are not absolute
    It’s true that PTE-based protection only provides a single privilege bit (user vs. supervisor). But that doesn’t make segmentation obsolete. In my design, paging and segmentation coexist — paging handles virtual memory, while segmentation, call gates, and task gates add an additional layer of structured isolation and control that modern kernels simply ignore.
  3. Manual control over hardware tasks is part of the experiment
    The article mentions that modern systems abandoned TSS task switching because of its side effects. I see that as an opportunity, not a problem. My kernel aims to use hardware tasks intentionally, with full understanding of those side effects — not to rely on them blindly, but to test and measure them directly.
  4. Real hardware testing is a feature, not a drawback
    Unlike portable or virtualized kernels, R4R runs directly on physical hardware. That’s not a limitation — it’s a commitment to 100 % hardware-level testing. Discovering and documenting how these mechanisms behave on actual CPUs is part of the goal. Even failure is progress if it reveals truths about the platform.
  5. If it fails, it still proves something valuable
    Whether this approach fully succeeds or not, it will stand as a concrete, working example that challenges long-held assumptions. Most people simply repeat what they’ve read about “why rings 1 and 2 are useless,” without ever testing it. I’m testing it.
In short: this project is not about portability or modern efficiency — it’s about learning from the bare metal.
Where others see “obsolete complexity,” I see unexplored capability.
Even a partial success here is a meaningful result, because it’s built on real experimentation, not theory.
 
Isoux said:
And now, a bold question for you — my dear friends here on the forum:

Do you think that the idea behind my little “project” deserves any attention on a platform where it could reach people who are genuinely interested in such things?

My greatest passion, first as an electronics enthusiast and then as a self-taught programmer, is simply to show how the hardware protection rings actually work — even if that concept might seem outdated today.
I truly believe it’s important, at least from a historical and educational point of view, that a demonstration like this exists somewhere, as a small proof of what these mechanisms were capable of.

To be honest, I don’t feel ready to handle deep technical questions from professionals — at least not yet. Maybe this project still needs to mature a bit more, to show more stable functionality… and perhaps I need to mature along with it.
Click to expand...
There are specialty forums for hobby-level electronics enthusiasts - like for Raspberry Pi, Arduino, and the like. I think those forums are a decent starting point for spreading the word about your project. Hacker News, Reddit, and OSDev are also viable options. I think that the key here is to actually have something for people to play with, and to have a thick skin for processing feedback.

When it comes to deep technical questions, there's no 'perfect' way to deal with them. But there are some pitfalls to avoid. A big one is pretending to know something when you actually don't - that's a no-no. I sometimes get asked something deep and technical. If I don't know the solution, I treat the question as a suggestion to learn more about the topic. It's not a job interview! If you actually know something, that does show in your comments - no need to push a bullshit CV down somebody's throat.
 
Isoux said:
As I mentioned before, firstly, I'm an amateur, secondly, GPT-AI suggested it to me, thirdly, I understood it as necessary because the val of 64 bit LDT descriptor array address is converted to a 32 bit (later in code pointer to 32 bit var) which is needed to fill the LDT descriptor with an offset or base ...?
Click to expand...

ChatGPT is useful and I use it daily but be aware: you have to always a possible double check information, at least ask for technical arguments. I asked GPT about double cast and see by yourself:

🧩 The role of the double cast

In this code:

Code: 
uint64_t ldt_devs[LDT_ENTRIES] = {0};
uint32_t base;

base = (uint32_t)(uint32_t)ldt_devs;

🎯 Why the double cast?

Code: 
(uint32_t)(uint32_t)ldt_devs

looks redundant — and it is.
Here are the typical reasons why someone might write that:

1. Historical/compiler behavior
Some older compilers complained when casting a pointer directly to an integer, so developers used an intermediate cast (e.g., through `uintptr_t` or `unsigned long`) to silence warnings.

2. Leftover or typo
Often it’s just a leftover from code refactoring, e.g. someone wrote:
Code: 
   base = (uint32_t)(uintptr_t)ldt_devs;
and later replaced `uintptr_t` with `uint32_t` twice by accident.

3. Intentional but meaningless
Double-casting to the same type doesn’t change the result. It’s functionally identical to a single cast:
Code: 
   base = (uint32_t)ldt_devs;
Click to expand...

GPT answers among its training, web information and your chat history; it could be biased. Not with the intention of deceiving anyone, the answers it gives are calculated for being the most probable.
 
Isoux said:
If you're interested in a bit of progress, you can check it out here: link
Click to expand...

Your new documentation is great 👍

astyle said:
There are specialty forums for hobby-level electronics enthusiasts - like for Raspberry Pi, Arduino, and the like. I think those forums are a decent starting point for spreading the word about your project. Hacker News, Reddit, and OSDev are also viable options. I think that the key here is to actually have something for people to play with, and to have a thick skin for processing feedback.
Click to expand...

A forum to talk about advanced topics like OSes development, in addition a narrow specific feature of x86 arch? I don't think so. I scrolled the OSDev forum for a few months, then I quit; it's useless; their documentation is useful.
 
I would like to explain why my project is currently stagnating. I have encountered certain obstacles, turning points, and possible new directions in further development — not in the sense of abandoning the original idea, but in order to avoid spending energy on recreating code that’s already functional and reusable, I want to rely on a complete operating system like FreeBSD, which has everything integrated..

While studying FreeBSD, I realized that I do not want to reimplement basic libraries and tools required for the practical functionality of my work, nor to eventually build an entire userland from scratch. For that reason, I decided to rely on existing FreeBSD versions in order to continue my work. I will certainly continue maintaining the repository containing the original R4R idea, but it will focus mainly on theoretical analysis and demonstration of minimal functionality.

My current idea is to use FreeBSD 2.2.8 on an i486 machine, as well as FreeBSD 6.2 on a somewhat more capable 32-bit processor. In that context, I would either adapt my idea to FreeBSD or adapt FreeBSD to my idea, depending on what proves to be more practical and sustainable.

In addition to that, I would like to gradually introduce ring 1 and ring 2 functionality into FreeBSD 14.x, the last release series that supports the i386 architecture. These rings would initially serve as auxiliary subsystems for the kernel (and possibly later for certain advanced parts of userland), implemented strictly in accordance with the existing FreeBSD style and philosophy.

For these ideas, I would fork the relevant repositories to my own GitHub account, so that the changes and progress could be followed publicly.

In this way, I hope to keep the project alive, continue learning and experimenting, and at the same time hear your opinions, suggestions, and criticism.
 
Isoux said:
I would like to explain why my project is currently stagnating. I have encountered certain obstacles, turning points, and possible new directions in further development — not in the sense of abandoning the original idea, but in order to avoid spending energy on recreating code that’s already functional and reusable, I want to rely on a complete operating system like FreeBSD, which has everything integrated..

While studying FreeBSD, I realized that I do not want to reimplement basic libraries and tools required for the practical functionality of my work, nor to eventually build an entire userland from scratch. For that reason, I decided to rely on existing FreeBSD versions in order to continue my work. I will certainly continue maintaining the repository containing the original R4R idea, but it will focus mainly on theoretical analysis and demonstration of minimal functionality.

My current idea is to use FreeBSD 2.2.8 on an i486 machine, as well as FreeBSD 6.2 on a somewhat more capable 32-bit processor. In that context, I would either adapt my idea to FreeBSD or adapt FreeBSD to my idea, depending on what proves to be more practical and sustainable.

In addition to that, I would like to gradually introduce ring 1 and ring 2 functionality into FreeBSD 14.x, the last release series that supports the i386 architecture. These rings would initially serve as auxiliary subsystems for the kernel (and possibly later for certain advanced parts of userland), implemented strictly in accordance with the existing FreeBSD style and philosophy.

For these ideas, I would fork the relevant repositories to my own GitHub account, so that the changes and progress could be followed publicly.

In this way, I hope to keep the project alive, continue learning and experimenting, and at the same time hear your opinions, suggestions, and criticism.
Click to expand...
Sometimes, a redesign does force a long and tedious re-factoring of the code so that the implementation fits the design. IMHO, if existing code compiles and runs, that's a good thing.
 
astyle said:
Sometimes, a redesign does force a long and tedious re-factoring of the code so that the implementation fits the design. IMHO, if existing code compiles and runs, that's a good thing.
Click to expand...
I completely agree. That’s precisely why I aim to keep any changes minimal,
well-isolated, and strictly experimental. The goal is not to redesign FreeBSD,
but to learn and explore what is possible while preserving existing, working
code.
 
You must log in or register to reply here.
Back
Top