OSDev.org

Hi,

rdos wrote:

Brendan wrote: It's normal to see other people's projects and be a little disappointed when you compare them to your own (especially when you see awesome screenshots like this). However, it is important to realise that these people will all start again themselves sooner or later (and when they do you'll be ahead of them!).

No way. You will never get ahead of me because I start from scratch.

But I will get ahead of you, eventually.

It might take a few years, but when it happens your OS will be surpassed in every way imaginable (code quality, design elegance, performance, scalability, features, etc).

After that, even though it'll be far better than the code you continue to struggle with, I might just throw it all away again. There are much larger things than RDOS that I need to surpass.


Cheers,

Brendan

Brendan wrote: It might take a few years, but when it happens your OS will be surpassed in every way imaginable (code quality, design elegance, performance, scalability, features, etc).

You forgot the most important: stability.

Brendan wrote: After that, even though it'll be far better than the code you continue to struggle with, I might just throw it all away again. There are much larger things than RDOS that I need to surpass.

Nice to hear that you have ambitions. I like that.

rdos wrote:You forgot the most important: stability.

I think that rock-solid stability is a self-evident feature of BCOS. All the extremity when it comes to handling errors, for example.

Stability doesn't mean that the BSOD works reliably.

Whenever you write a non-trivial amount of new code, you'll introduce bugs. Over time, these bugs get fixed and the code matures. Each time to start over, you lose all of the confidence in existing code because everything is new. So I'll never trust that a project that has started over just a while ago has rock-solid stability.

Hi,

Kevin wrote:Whenever you write a non-trivial amount of new code, you'll introduce bugs. Over time, these bugs get fixed and the code matures. Each time to start over, you lose all of the confidence in existing code because everything is new. So I'll never trust that a project that has started over just a while ago has rock-solid stability.

Whenever you write a non-trivial amount of code:

• without prior experience
• without reference code to guide you
• without breaking it up into small/manageable pieces
• without doing any unit tests
• without doing adequate testing on real and emulated hardware
• without any form of quality control
• without much in the way of fore-thought or design

You will create a higher number of bugs, and will take a lot longer to find those bugs.

Therefore, I recommend that nobody does any of these things, and we all just give up writing any software for any reason, and we hide under a blanket in the corner of our bedrooms crying like a small child instead.

However, there is still one hope! If you're trying to add a radically different/new features to an old tangled mess of spaghetti, then you will magically become immune to all bugs!


Cheers,

Brendan

Don't be silly. All I'm saying is that bugs in code that has been in use for some time are more likely to have been reported and fixed than bugs in brand new code. That is, code matures over time. If you rewrite from scratch, you throw away the maturity and therefore also some confidence in its stability.

We can't talk without narrow down the context a bit, so let me put up an example.

On my experience, I would rewrite some of my code (not related to OS) that is 5~10 years ago, even it is proven to be bug free for being in production environment for years; simply because it did not scale well on modern machine (or utilize memory, or changes in direction for optimization), when it was designed there was not much multi-core nor multi-cpu machine. On the other hand since I had working on that piece of software for years I have confident to make very few mistake and most important, once an issue is discovered I have reference case(bug tracker of old branch) to look at any suspect and fix that quickly.

However, there are a lot to consider when planing to rewrite from scratch, it's not always justified.

Hi,

Note: There are 2 types of bugs - "irrelevant bugs" and "hidden bugs". The irrelevant bugs are bugs that are typically found and fixed within 2 minutes (e.g. due to compile time errors and/or obvious run-time problems). The hidden bugs are bugs that can lurk in code undetected for a relatively large amount of time (e.g. symptoms only appear under certain/specific conditions). The remainder of this post ignores the "irrelevant bugs", and only talks about the "hidden bugs".

Kevin wrote:Don't be silly. All I'm saying is that bugs in code that has been in use for some time are more likely to have been reported and fixed than bugs in brand new code. That is, code matures over time. If you rewrite from scratch, you throw away the maturity and therefore also some confidence in its stability.

Your argument might make sense for something like Gnome or Microsoft Office or Oracle Database, where the code actually has been used and tested by many people on many computers. However...

It does not make sense for almost everyone here, where the supposedly "well tested mature code" has never actually been used on any production system; and has probably spent a total of less than 4 hours being "partially tested" (due to never having many real applications, drivers, etc) on less than 5 computers.

Due to this "there is no mature code to begin with" problem; what you're really suggesting is "don't replace old code (that was written when you had less experience and is therefore probably full of hidden bugs) with new code (that you will write when you've got more experience and will therefore probably have less hidden bugs)". Can you see how, in the context of hobby OSs, this is completely idiotic?

What it really comes down to is development time. If you're planning to make significant changes to the design, then rewriting from scratch (and avoiding the constant hassle of trying not to break existing code) is faster (and will probably reduce the amount of hidden bugs); and if you're only planning to make minimal changes to the existing design then evolving old code is obviously faster (but probably won't reduce the amount of hidden bugs).


Cheers,

Brendan

Brendan wrote: Your argument might make sense for something like Gnome or Microsoft Office or Oracle Database, where the code actually has been used and tested by many people on many computers. However...

It does not make sense for almost everyone here, where the supposedly "well tested mature code" has never actually been used on any production system; and has probably spent a total of less than 4 hours being "partially tested" (due to never having many real applications, drivers, etc) on less than 5 computers.

Not so. Maturity doesn't come suddenly, but gradually. That means it is relevant for typical hobby-OSes as well. If you used a lot of time for developping drivers, and possibly test applications, you can do much better tests than if you just started writing a new boot-loader and kernel, that basically can run nothing, neither drivers nor applications.

Brendan wrote: Due to this "there is no mature code to begin with" problem; what you're really suggesting is "don't replace old code (that was written when you had less experience and is therefore probably full of hidden bugs) with new code (that you will write when you've got more experience and will therefore probably have less hidden bugs)". Can you see how, in the context of hobby OSs, this is completely idiotic?

Not the same thing. I've replaced basically all code from the 90s, without doing any complete rewrite or starting from scratch. What that means is that the new code had much better test-cases than if I'd rewritten everything from scratch, where basically nothing would be testable. Much of the old code did not have any test-cases at all, and also wasn't regularily tested in the kernel debugger either, as that was before I made that tool. If I'd do a complete rewrite, basic functionality (paging, physical memory handing, scheduling and SMP) would have no test-cases, and thus would need years to become stable. Even almost trivial bugs in the SMP implementation or in locking could lurk for very long before even getting detected without adequate testing.

Lets take the implementation of PAE (and long-mode) paging in RDOS as an example. This was done in the present code-base, and thus could be put to elaborate tests from drivers and userland. If you write long mode paging from scratch, you would have no test-cases whatsoever, since paging is basic. The same goes for the recent change to the physical memory allocation, which could be stressed by present drivers and applications. Even the long-mode pagefault handler could be partially tested by using faults from 32-bit drivers.

Edit: And despite of this initial testing and stressing, I still missed a trivial bug in the physical memory handler, and I missed that the SMP scheduler could mess-up on single-core CPUs and let an unbehaved task run forever, locking out everything at the same priority-level.

I'd like to state that OS code written without proper debugging and stress-testing tools is "alpha", and highly unreliable, and needs to be replaced (or properly debugged/stressed, which is tedious and very time-consuming) before being considered stable. Then if you start your cycle from scratch every time, all your code will be in alpha-state all the time, regardless how sophisticated your system eventually becomes. I bet that the time you can save in the development cycle will multiplied by ten and used-up in finding the bugs when the code becomes more mature. However, if you never aim to approach a stable release, it seems like the start-over approach might be efficient, as you can spend a lot of time on development and not so much on bug-fixing.

I agree with the irrelevant bugs, let's ignore them.

Brendan wrote:It does not make sense for almost everyone here, where the supposedly "well tested mature code" has never actually been used on any production system; and has probably spent a total of less than 4 hours being "partially tested" (due to never having many real applications, drivers, etc) on less than 5 computers.

There's certainly some truth to this, but at some point the past testing starts to be valuable, though I'm not totally sure where to draw the line. I think it might already the case if I was the only tester, but I have tested some driver on a machine that I don't have access to any more for testing the new version.

I don't expect that anyone has used tyndur for production, but it's definitely tested on more than 5 real computers and much more so on emulators (which aren't all that helpful for testing hardware support, but there's enough code in an OS to find pure software bugs even there).

Due to this "there is no mature code to begin with" problem; what you're really suggesting is "don't replace old code (that was written when you had less experience and is therefore probably full of hidden bugs) with new code (that you will write when you've got more experience and will therefore probably have less hidden bugs)". Can you see how, in the context of hobby OSs, this is completely idiotic?

The point where we disagree is probably that bugs are caused by lacking knowledge. Yes, I absolutely agree that you'll gain experience and if you rewrite the code, it may look much nicer in the end. This may be relevant for readability, maintainability, modularity and whatnot. I don't think it's overly relevant for bugs and I claim that most bugs are not created by a lack of experience, but simply brain farts while writing the code. And you'll always have these, no matter how big your experience is.

What it really comes down to is development time. If you're planning to make significant changes to the design, then rewriting from scratch (and avoiding the constant hassle of trying not to break existing code) is faster (and will probably reduce the amount of hidden bugs)

No, it will just exchange some old bugs for some new ones.

Status report: this rewriting from scratch has worked very well for me so far. However, I only have about two hours per day to do development work. Progress is slow but steady.

I think that "mature code" is a little bit overvalued. I have only seen inelegant long source code files with thousands of modifications, compiler specific hacks, workarounds added on workarounds etc. However, the whole mess is stable because it usually has many testers (and users). It is stabilized by using brute force.

Antti wrote: I think that "mature code" is a little bit overvalued. I have only seen inelegant long source code files with thousands of modifications, compiler specific hacks, workarounds added on workarounds etc. However, the whole mess is stable because it usually has many testers (and users). It is stabilized by using brute force.

Not necessarily. If the code and/or interface is messy has more to do with it becoming widely used in a messy state. Once an interface is widely used changing it will mean breaking existing code. However, this is not relevant for a typical hobby-OS project, as it is possible to make radical changes in the interface / code even if it is used by some applications. You just make the changes, recompile the code, and fix what is broken. I do this from time to time. I definitely won't accept spaghetti-code, nor messy interfaces.

I think rewriting OS is good practice at least from my point of view. I did it many times but always because of design changes.
At first time I written my OS in RealMode with something like DOS command line. Only keyboard & graphic hardcoded into kernel. Next time I wanted to add ProtectedMode so there where only one solution, just make a different design and new implementation. So I written 32bit OS in PM and again I made simple command line support. But I have no paging, drivers, memory allocation, ...
Now I wanted to add support for my driver system. So I made new design and started to writing and didn't finished because I figured out that paging might be needed. Then I learned basics of paging and made new design. This schema repeats all the time. Now I wanted to write OS with LongMode and obviously I started from new design and now I am implementing it.

The main reason why I am doing OSDEV is just I very like designing and checking if I could make implementation. It is obvious for me that I never going to complete whole OS but designing/writing it is just my main goal. In rewriting process I noticed that when I write the same code again I made it faster, code is smaller and because of that I better understand it.

As to the bugs. I didn't noticed that number of bugs I made is increasing/decreasing in large number, it is rather on the same average level. But I get the experience to find them and prevent next time I write the same code. But unfortunately I create bugs in other places.

nevar wrote:I think rewriting OS is good practice at least from my point of view. I did it many times but always because of design changes.

That is self-contradictory. It means your design was bad. This is the very reason for which so many software design books exist.

(I didn't read the rest.)

Personally, I don't want to write the same code twice, which is why I never want to start from scratch.