OSDev.org

I'm a computer engineering student.
We (as a 15-members team) tend to make our graduation project as OS.
Is this good idea?
If so ,we know nothing about developing OS,can someone just list the steps in details (as proposal) describing the whole story ?
Thanks in advance.

Is this good idea?

Everyone here thinks writing an OS is a good idea.

Start with the wiki.

Keep in mind that even teams working on an OS can take a long time to get anywhere - don't expect a shiny GUI or anything if all you have is a year. That said, I was able to write a small POSIX-capable OS with a custom shell and GCC/binutils in 4 months.. so it's not impossible to do something cool with minimal amounts of time.

That said, if you've already got a fair bit of experience writing application code, and as such know your language inside out... you should be able to get a simple OS up and running ready for your graduation project.

Thanks all.

Everyone here thinks writing an OS is a good idea.

I ask as a graduation project not generally.

Can someone list the steps,i need it for time estimation .. Just headlines.
I'm that what I got from searching is so little compared to the actual experience and things will appear with work.
i.e. -kernel:
-memory management
-...
-.....
-processes.
-..
-Drivers
....

So,if one could help .. it will be a great favor !
Thanks

Hi,

mahmoudaladawi wrote:

Everyone here thinks writing an OS is a good idea.

I ask as a graduation project not generally.

If there's a deadline then I'd say "bad idea", especially when there's a team of people involved (where simple decisions can take months of debate, and progress is harder to predict). A more practical alternative is to limit scope at the beginning. For example, if you say that you're planning to write a micro-kernel for 32-bit 80x86 that could be used as the basis of an OS one day then you're far more likely to acheive that goal; and if you say you're planning to write an OS then your chances of completing it is almost zero. With luck, at the end of the day (when it's time to hand in your work) you'll have a kernel with some device drivers and some other stuff, and you want to be able to say that you achieved the original goal (and then added extra software on top) rather than saying you failed to achieve your goal (because you've only got a kernel and some device drivers, and no GUI or networking or whatever). Mostly it's exactly the same work (just a different definition of "success").

Also note that I wrote "micro-kernel" for a reason - it allows large parts to be left until later, and would help to reduce the "simple decisions can take months of debate" problem by reducing the number of decisions that need to be made while creating the kernel. For example, if someone thinks a fancy video framework is necessary, then you can just nod your head and say "I agree, but it's not part of the micro-kernel, and we should finish the micro-kernel first." rather than arguing about feature-creep and deadlines.

mahmoudaladawi wrote:Can someone list the steps,i need it for time estimation .. Just headlines.

For "minimum development time", "minimum features" and "minimum quality", you could probably start with GRUB (1 day or less to get started), then after the first week have basic (text mode) console working and physical memory management done. Second week you could have basic virtual memory management mostly complete and be looking at scheduling. After the third week you could have a simple scheduler working, and maybe after 4 weeks have IPC done. Then you could put some sort of process loader on top, do a little polishing and call it a micro-kernel after about 5 weeks.

Of course with "minimum features" and "minimum quality" it'd be mostly useless. If you start with a well designed abstraction layer between the boot code and the micro-kernel, and then take into account things like portability, performance (and/or "hard real-time"), multi-CPU, fault tolerance, device management, power management, etc then it could take several years before you've got a working alpha version of a micro-kernel...


Cheers,

Brendan

There are ready-to-go tutorials for unix clones, so basically you can do that and you have a working minimal OS. From there on there's little to say about what steps to take without any mention about what your project should actually do. Basically you can get one of the larger tutorials - brokenthorn or james molloy's - print out the list of chapters, and you have a tasklist for a basic kernel. What concerns me though, is that a graduate subject should normally involve new research, writing a basic kernel is little more than a programming exercise. Every idiot can copy-paste together a kernel if he is able to follow instructions.

In other words: what are your final goals. Since you seem to have about 6 years worth of man-hours, you need more direction than "I want an OS". Combined you have a lot more time than what Linus spent on the first version of Linux. And as students, making such decisions should not be a matter of months, unlike what Brendan seems to suggest. It basically comes down to cutting down the system to components then assign those components to your teammates. In the end, success is more a problem of good project management rather than programming issues - there's a ton of free code around to grab, and for academic use you might not even need to bother with licensing issues if you don't intend to publish anything.

That said, what do you actually want to achieve? What does the assignment expect that you achieve?

Hi,

Combuster wrote:In other words: what are your final goals. Since you seem to have about 6 years worth of man-hours, you need more direction than "I want an OS".

Hmm - to be honest, I've got no idea how much time is allowed. I assumed "from now until near the end of the year", or about 5 months. For 5 months with one person, allowing 2 months for the micro-kernel (without plagiarism/tutorial code) and 3 months for "extras" seems about right to me. For 5 months with 15 people, allowing 3 months of debating design issues, followed by 1 month of writing code and then another month of rewriting the code due to design changes seems about right to me too.

I'm not sure, but maybe you're calculating "5 months * 15 people = 75 mythical man months" (which happens to work out to "about 6 years worth of man-hours").

I'm also unsure about the "new research" part of it. If every graduate did new research, then they would've mostly exhausted the finite-sized pool of potential new ideas in the 1960's, and by now they'd be resorting to rehashing old stuff (e.g. call it a "cloud" and pretend it's a new idea).


Cheers,

Brendan

Brendan wrote:I'm also unsure about the "new research" part of it. If every graduate did new research, then they would've mostly exhausted the finite-sized pool of potential new ideas in the 1960's, and by now they'd be resorting to rehashing old stuff (e.g. call it a "cloud" and pretend it's a new idea).

If the pool were to be finite, you couldn't add anything that didn't exist already. So every use for electricity couldn't have existed before electricity was invented. So computers wouldn't exist. Computers exist. Contradiction. Conclusion: the pool of ideas is infinite. Your point is based on an invalid premise and thus logically holds no value.

In short: research leads to inventions leads to new research topics.

That does not take away that people rebrand old stuff to sound geeky - any sufficiently advanced technology is after all indistinguishable from magic

There can't be an infinite number of ideas - perhaps close to it but not infinite. There are only so many ways you can put elementary particles together and only a small subset would even make sense. But I'm just being pedantic.

-Thank you all for help.

-If there are no new ideas ,so tell Google,IBM,Microsoft,intel.. to close as the are no work for them to do !
One can make revolutionary change ,innovation exists with man.

-The time is till July-2011.

-About research ,of course we will apply our own ideas which we see that are better than those already exist .. or we are just implementers and repeat the other work.

-One of subjects which is not clear to me is GUI ,why all say that it's the hardest part..i've read about graphics programming Vga,svga,..VESA and i read from 'Intel' that XP uses vesa when we install it before installing driver.So,all that neat job made by vesa !!
-Can we use graphics libraries of C ,there are a lot of them which make great job.

Thanks again..

mahmoudaladawi wrote:-One of subjects which is not clear to me is GUI ,why all say that it's the hardest part..i've read about graphics programming Vga,svga,..VESA and i read from 'Intel' that XP uses vesa when we install it before installing driver.So,all that neat job made by vesa !!

Maybe you should focus on a command line interface rather than a full blown GUI. You should spend more time under the hood, don't get lost in the eye candy. GUIs are not interesting from a technical point of view...

VESA standardized an extension called VBE. You're refering to VBE/Core, in particular. Basically, all compliant video cards have BIOS code in their ROM which you can use. It's slow (no hardware acceleration to begin with) but it will do the job in the absence of a native driver. Be warned that if this is an x86-64 OS you will need to write a real mode emulator as well - more work that has nothing to do with OS theory.

-Can we use graphics libraries of C ,there are a lot of them which make great job.

You cannot unless you adopt the same interface as the OS for which the library is built. Even if you want to port them, you will have to provide a big deal of functionality...

mahmoudaladawi wrote:-About research ,of course we will apply our own ideas which we see that are better than those already exist .. or we are just implementers and repeat the other work.

If you want to implement something, I might suggest doing an implementation of seL4? It's a research microkernel that has a solid design, but the implementation has not been publicly released yet. As far as I know it is free to implement, but you certainly would want to double-check that. Here you have the benefits of concentrating on something small AND not even have to design anything, as the interface specification is freely available (heck, it's even been formally verified!) Just an idea for you.

kabure wrote:I might suggest doing an implementation of seL4?

But there is no resource there just lines about the project ,am i wrong ?

-I have a question about when the formats come?
.exe ,.bin,.... programs setup sources !

Thanks

After you have a way to create processes, then you'll need a way to load processes(programs), then you'll need a way to format(exe, bin, etc) your process image segments.

I think that team of 15 inexperienced programmers is way too big.
Also, your goals should be very humble...build the system with components simple enough just to provide basic function.
So ultra "simple" output(text mode), kernel(mm, scheduler, IPC, drivers....). After you build such a system, you will posses knowledge and experience to rewrite or upgrade each of this components to produce much better system. You won't go through technical issues, but they will be more of the theoretical nature. To achieve that, you need a team of dedicated people and I really doubt that all of them are....heck...maybe if 2 or 3 are I would consider it good.