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.
 
You must log in or register to reply here.
Back
Top