Ideas for an undergrad/masters level OS project

[madanra]

Hi,

I'm hoping to do an OS project next year at uni (4th year of an undergrad masters course, the project counts for a third of the year), and I was wondering if the wonderful OSDev community has any ideas?
I don't have any noticable amount of my own OS code, so if I were to try and do a completely-my-own project it would essentially be from scratch, which I don't think is practical for this size project! My supervisor-to-be suggests doing something based on Minix. My only real idea so far for Minix would be involving implementing kernel level POSIX threads.

Thanks!

[MDM]

Turn Minix into a monolithic, Linux-like kernel.

Andrew Tanenbaum would go to your location and kill you.

Personally, I'd find a small OS thats even only partially posix compliant to be more impressive than a posix thread implementation.

[JackScott]

Minix are very much involved in the Google Summer of Code project. Why don't you pick one of the tougher leftover subprojects after that's all wrapped up? There's sure to be something left that you can sink your teeth into.

Alternatively, ask the Minix developers if there is anything they need?

Also, MDM, berkus is a troll. Ignore him.

[Brendan]

Hi,

I'm hoping to do an OS project next year at uni (4th year of an undergrad masters course, the project counts for a third of the year), and I was wondering if the wonderful OSDev community has any ideas?
I don't have any noticable amount of my own OS code, so if I were to try and do a completely-my-own project it would essentially be from scratch, which I don't think is practical for this size project! My supervisor-to-be suggests doing something based on Minix. My only real idea so far for Minix would be involving implementing kernel level POSIX threads.

Do a research paper (and code) to compare the scalability of IPC alternatives for micro-kernels, that proves synchronous messaging and "fixed size" messaging suck dog balls for modern ("many-CPU") systems. It could also explore the effects messaging/IPC design has on the final system, and the conclusion could explain that idiots who try to make micro-kernels look like Unix are morons.


Cheers,

Brendan

[madanra]

...idiots who try to make micro-kernels look like Unix are morons.

You don't like Minix then, I guess

[Brendan]

Hi,

...idiots who try to make micro-kernels look like Unix are morons.

You don't like Minix then, I guess

Maybe an analogy would explain it best...

Imagine you're designing a new power plant that will use methane instead of coal. You have a look at how existing coal power plants work, and decide to use the methane to heat water into steam and use the steam to drive turbines that rotate generators. That will work, but it'd also be stupid - if you forget about how existing coal power plants work, then you might use the methane in an internal combustion engine to drive the generator instead and get a lot better efficiency.

Imagine you're designing a new kernel that will use IPC instead of direct procedure/function calls. You have a look at how existing Unix systems work and decide to use synchronous messaging to replace the procedure/function calls. That will work, but...


Cheers,

Brendan

[MDM]

Hi,

...idiots who try to make micro-kernels look like Unix are morons.

You don't like Minix then, I guess

Maybe an analogy would explain it best...

Imagine you're designing a new power plant that will use methane instead of coal. You have a look at how existing coal power plants work, and decide to use the methane to heat water into steam and use the steam to drive turbines that rotate generators. That will work, but it'd also be stupid - if you forget about how existing coal power plants work, then you might use the methane in an internal combustion engine to drive the generator instead and get a lot better efficiency.

Imagine you're designing a new kernel that will use IPC instead of direct procedure/function calls. You have a look at how existing Unix systems work and decide to use synchronous messaging to replace the procedure/function calls. That will work, but...


Cheers,

Brendan

Isn't the idea of a micro kernel though the same idea as stated in your signature ( "Slow code that scales better can be faster than fast code that doesn't scale!" ). So are you against micro kernels in general, or micro kernels that attempt to conform to unix likeness? What about hybrid kernels? (note, I am unsure if aggression will come across in this post so I would like to state that you undoubtedly are much more knowledgable in this area, and I am just looking for opinions. This is by no means meant to be an aggressive post).

[Combuster]

Two things:
- Scalability is not performance; Microkernels and scalability are unrelated. Microkernels run drivers in ring 3 rather than ring 0. Ring transitions alone do not affect scalability, they do affect performance. The signature only says that a slower but scalable system may eventually perform better than a system that uses a faster algorithm but does not scale: A well designed microkernel is probably faster than a poor macrokernel; a well designed monolithic OS may be faster than a poor Microkernel implementation.

- If you read the post, the aggression was not directed at microkernels at all, but rather at people needing compatibility layers. Microkernels generally have a different native programming model than macrokernel systems. If you have programmed for both the Symbian API and the DirectX API, you'd know what world difference exists between the two.

[MDM]

Ah, thank you for the corrections.

In my own OS I have been attempting to use my own standard as well as implement a POSIX compliant layer so I can run a large amount of unix programs, would you say that is a useless goal or that it'd only become a mistake to make posix compliance the primary goal for the OS (it's a hybrid kernel leaning in the direction of a Microkernel)?

[Combuster]

It's a bit of a religious question, but Posix is IMO for those that only seek an exercise and don't actually dare to be truly different.

[Solar]

The advantage of POSIX compliance is that you immediately get access to the plethora of Unix userspace tools.

The disadvantage of POSIX compliance is that you immediately get access to the plethora of Unix userspace tools.

It's one thing to have an established software base, and then adding a POSIX layer for convenience (Windows -> Cygwin, or AmigaOS -> libnix back in the 90'ies). You add value to your platform, but tools using that layer remain a niche because your system offers a much better user / developer experience than the POSIX tools do.

But for a newly-bred OS, going for POSIX compliance is a bad thing, IMNSHO.

One, you tend to shackle yourself to the limitations of POSIX: "Can't do it that way, I'd lose POSIX compliance." (POSIX was never designed to fit a microkernel, for example...)

Two, why should people use your API to create new, better, slicker tools when they could port over POSIX tools so easily? Why should anyone even bother to read your API docs when they already know POSIX by heart? What kind of "wow" effect, do you think, is generated by a bash shell in a X terminal showing the output of "ls -l"? The few followers you might have will be tied up doing ports, instead of doing your system real justice and exploiting its superior functionality by creating native applications?

That is, of course, assuming that your OS does provide superior functionality worth exploiting. If it doesn't, you're screwed from the beginning, and will always play "catch-up" with the other platforms. Like AmigaOS does these days, hobbling from one port of years-old POSIX software to the next - they got GIMP 2.4.7 now, can you believe it? Back in the good days they had ArtEffect, ImageFX or AdPro, today they have what Linux discarded long ago...

[MDM]

Thank you, Solar, and Columbuster for the insight!

[gerryg400]

The advantage of POSIX compliance is that you immediately get access to the plethora of Unix userspace tools.

The disadvantage of POSIX compliance is that you immediately get access to the plethora of Unix userspace tools.

It's one thing to have an established software base, and then adding a POSIX layer for convenience (Windows -> Cygwin, or AmigaOS -> libnix back in the 90'ies). You add value to your platform, but tools using that layer remain a niche because your system offers a much better user / developer experience than the POSIX tools do.

But for a newly-bred OS, going for POSIX compliance is a bad thing, IMNSHO.

One, you tend to shackle yourself to the limitations of POSIX: "Can't do it that way, I'd lose POSIX compliance." (POSIX was never designed to fit a microkernel, for example...)

Two, why should people use your API to create new, better, slicker tools when they could port over POSIX tools so easily? Why should anyone even bother to read your API docs when they already know POSIX by heart? What kind of "wow" effect, do you think, is generated by a bash shell in a X terminal showing the output of "ls -l"? The few followers you might have will be tied up doing ports, instead of doing your system real justice and exploiting its superior functionality by creating native applications?

That is, of course, assuming that your OS does provide superior functionality worth exploiting. If it doesn't, you're screwed from the beginning, and will always play "catch-up" with the other platforms. Like AmigaOS does these days, hobbling from one port of years-old POSIX software to the next - they got GIMP 2.4.7 now, can you believe it? Back in the good days they had ArtEffect, ImageFX or AdPro, today they have what Linux discarded long ago...

Solar, you make it sound like my OS is a waste of time. And of course it is. Luckily I'm only doing this (Posix microkernel) for fun.

BTW, co-incidentally, last night I got coreutils 'ls -an /usr' to work in my dash shell reading an ext2 filesystem. ('ls -l' hung trying to read my non-existant passwd file). I know it's completely pointless. I know it's all been done before. I know no-one else will ever care. But I can't stop.

Now, if I were doing an undergraduate project, I'd take up Brendan's challenge. I'd build a proper Posix style, synchronous-messaging, SMP microkernel and find out whether it really does suck.