OSDev.org

My targets are programmers for the first time, but next I will try to make my OS both flexible and user-friendly to be able to target users unfamiliar with programming and system administration.

b.zaar wrote:

Jezze wrote:alternative solutions to things operating systems have been able to do for decades already.

What kind of solutions? What's an example?

Its really not that revolutionary but since my operating system is designed with no memory management it really forces you to think outside the box. The biggest problem but also the greatest challenge is that in most cases you cant copy other oses solutions because they dont fit the design. You cant do sloppy implementations and just take some arbitrary memory and put something there. Instead you need to think hard about your design because the only objects you have to your disposal need to already exist. In some cases like in my device driver interface it actually led me to a very small but powerful solution something I would never had figured out without this limitation. Besides that another thing I aim for is to do as little fault handling and alternative code paths as possible inside the kernel by making as few options as possible. There are no flags when issuing syscalls for example. Another big thing is in userspace where programs dont take arguments and forking rotates the file descriptors so piping data becomes a natural thing. All of these things already exists but they are implemented differently and in my oppinion in a much more natural way.

Jezze wrote:my operating system is designed with no memory management it really forces you to think outside the box.

Is this a permanent thing or just in the current development?

What's your reasoning?

Jezze wrote:The biggest problem but also the greatest challenge is that in most cases you cant copy other oses solutions because they dont fit the design. You cant do sloppy implementations and just take some arbitrary memory and put something there. Instead you need to think hard about your design because the only objects you have to your disposal need to already exist. In some cases like in my device driver interface it actually led me to a very small but powerful solution something I would never had figured out without this limitation.

How is your DDI designed then?

I don't want to hijack this thread but since you asked I'll reply. The reasoning is I think keeping track of memory is something that in large complex systems is an exceptionally complex task. Anyone who thinks they can grasp it is probably delusional. If I use dynamic memory allocation I can not trust myself that the system will be able to allocate and free memory correctly in all situations. If I don't use it, a compiler will to a greater extent find most of the problems in my code through static analyzis, something that is near impossible in a system with dynamic memory allocation. Also there are other side effects to consider, you have memory fragmentation and the added time to allocate and deallocate memory which depending on the memory allocator and how the system is used can vary greatly. I also think, and this is questionable i know, is that in many ways dynamic memory is a last resort many has to take because there is no other option available when the system does not allow or provide you with proper interfaces due to poor design.

The DDI is still under construction and kinda hard to explain properly but basically it does away with the what is typically known as the device construct. It only has a bus construct that provides a function to iterate over bus-specific unique identifiers (one identifier represents a device you could say), and a driver construct that if it matches one of these identifiers will provide an interfaces to that bus and they communicate between eachoter using this interface and that identifier. Because of the lack of dynamic memory allocation a driver will only work for one device at a time so if you say have two network cards you need to have two physical copies of the same driver so basically a .ko.0 and a .ko.1 file. This might sound weird but I noticed that inside the driver the more difficult problems became trivial while some of the easier stuff became a bit clunkier but the net result felt like a win. Plus, it's not that often you have two of the same device in the real world is it? And it's just different and nobody does this so I want to give it a go.

Jezze wrote:I don't want to hijack this thread but since you asked I'll reply. The reasoning is I think keeping track of memory is something that in large complex systems is an exceptionally complex task. Anyone who thinks they can grasp it is probably delusional.

I think you're the delusional one... It's a fairly straightforward process, you're just failing to understand it.

Jezze wrote:If I use dynamic memory allocation I can not trust myself that the system will be able to allocate and free memory correctly in all situations.

You never should anyway because you don't have an infinite amount of memory. That's what error checking is for.

Jezze wrote:If I don't use it, a compiler will to a greater extent find most of the problems in my code through static analyzis, something that is near impossible in a system with dynamic memory allocation.

Nope. It's perfectly possible, you just don't know how to do it.

Jezze wrote:Also there are other side effects to consider, you have memory fragmentation and the added time to allocate and deallocate memory which depending on the memory allocator and how the system is used can vary greatly.

That's why there are different memory managers. The operating system doesn't handle it. It just provides sbrk and brk functions that either increase or decrease the number of memory pages used by a particular program. These pages are virtual, translated into physical addresses by the MMU; so there's no need to worry about continuity. Libraries like malloc and talloc, which are part of the C runtime that the program is linked against, are responsible for micro-managing this memory given to them by sbrk/brk.

Jezze wrote:I also think, and this is questionable i know, is that in many ways dynamic memory is a last resort many has to take because there is no other option available when the system does not allow or provide you with proper interfaces due to poor design.

It's not a last resort, it's an only resort. If the machine doesn't have an MMU to translate virtual addresses into physical ones, you have make use of either position independent code and/or overlays. An art of programming that has pretty much died since the introduction of MMU's.



EDIT:
Funny story, I once asked a question on stack overflow about the use of overlays, and people were completely oblivious as to what I was talking about. I had to explain to them what an overlay was, and my question went both unanswered and thumb-down'd.

The algorithm you use to allocate and deallocate might be straightforward but when I ment grasp I was thinking more in the terms of what programmers call side-effects or the set of states your system can be in. The number of states even without dynamic memory management is huge and with dynamic memory management it will grow even more astronomical. This makes it even harder to reason about the behaviour of your system so say given a current state X, what sort of predictions can you do about state Y after say duration T.

Dynamic memory management is far from the only culprit in this and for most people I guess they just don't give a damn about it. I just think it is important for a system to have a close as possible set of worst case/best case scenarios.