OSDev.org

Hi. Newb here. I'm a moderately skilled C programmer, and I've been using linux for some things.(not web browsing. ) Anyway, I've been thinking about it, and I got it into my head that I would like to code my own operating system. I don't have any great expectations for it, except for the uses that I will be using it for. I don't need it to compete in the os wars or anything.

Essentially, the kernel will handle process scheduling and memory management, while I/O will be handled by two parts outside the kernel: A basic library framework that takes care of the redundancies across device i/o, and individual programs that manage individual types of devices.

My rationale for doing this is that I really don't want to waste years integrating all the various hardware components with the kernel code, which would really be a nightmare. I figure this way, I can speed up development for new hardware simply and flexibly, at not too great a cost.

Also, I'll try and speed up the system by excluding code for a system clock in the kernel. Instead, I will simply update a counter which will be used to calculate the system time whenever a program in userspace requests it. I figure it would be simple enough to add a "time" command to the command line instead of constantly updating a clock that may or may not be needed by the user.

Also, I think I could reduce complexity by making it a single user system and thus eliminate the need for user ID's. Add to that an ext3 filesystem, basic networking support, and a handful of text editing programs, and I'll pretty much have version 1.0 up and working.

I think It'll be fun, actually. I'm looking forward to working out the excruciating error codes I recieve with you guys.

Wish me luck!

:edit:
Hmm... probably should have posted this in the appropriate forum. Doh!

Hi!

Wish me luck!

Wish you luck!

Daniel.

Iznasilov wrote:Also, I think I could reduce complexity by making it a single user system and thus eliminate the need for user ID's.

What a great idea, I wonder why nobody's thought of that before.

Brynet-Inc wrote:

Iznasilov wrote:Also, I think I could reduce complexity by making it a single user system and thus eliminate the need for user ID's.

What a great idea, I wonder why nobody's thought of that before.

A hobby OS is not the same as a production OS brynet(security nut) lol

All in all, I think your idea sounds pretty sane for a new comer. At last a person not wanting to emulate linux mac and windows.

earlz wrote:A hobby OS is not the same as a production OS brynet(security nut) lol

Just like a pink tricycle is no tank, but perhaps if we put enough paint on it... it'll stand a chance, right?

Iznasilov wrote:Essentially, the kernel will handle process scheduling and memory management, while I/O will be handled by two parts outside the kernel: A basic library framework that takes care of the redundancies across device i/o, and individual programs that manage individual types of devices.

My rationale for doing this is that I really don't want to waste years integrating all the various hardware components with the kernel code, which would really be a nightmare. I figure this way, I can speed up development for new hardware simply and flexibly, at not too great a cost.

Drivers.

Also, I'll try and speed up the system by excluding code for a system clock in the kernel. Instead, I will simply update a counter which will be used to calculate the system time whenever a program in userspace requests it. I figure it would be simple enough to add a "time" command to the command line instead of constantly updating a clock that may or may not be needed by the user.

That's not really how things work. Not to mention that even constantly updating anything as simple as a clock won't slow down the system. Well maybe it would but you wouldn't notice it until a few hundreds of thounds of years later.

earlz wrote:

Brynet-Inc wrote:

Iznasilov wrote:Also, I think I could reduce complexity by making it a single user system and thus eliminate the need for user ID's.

What a great idea, I wonder why nobody's thought of that before.

A hobby OS is not the same as a production OS brynet(security nut) lol

I really hope that's double sarcasm, and Byrnet-Inc isn't the only one

Also, I think I could reduce complexity by making it a single user system and thus eliminate the need for user ID's. Add to that an ext3 filesystem, basic networking support, and a handful of text editing programs, and I'll pretty much have version 1.0 up and working.

Don't get ahead of yourself. It'll take you a few years before you can get that far, esp. since you have no prior experience in systems programming.

Wish me luck!

G'luck!

Iznasilov wrote:Hi. Newb here. I'm a moderately skilled C programmer, and ...

In case you're being serious, I think the best way to start off is to thoroughly know a good, solid, flexible language for use in development. Maybe you could try to learn C properly, by reading a good book on it.

Another good piece of advice is to...know your development language inside out. You could probably get to work on that by purchasing a good, solid, well known book on C.

Last but not least, you'll find that if you don't know your chosen development language as well as your primary spoken language, you'll run into some bumps along the way. I recommend you search out some good C programming references and delve into them like there's no tomorrow.

-All the best
gravaera

Hi,

Iznasilov wrote: Wish me luck!

Good luck!

-- Andrew

P.S Do you know Russian? I thought this because of your nickname..

Edited: Sometimes my brain it don't work too well (I'm not sure even a steady caffeine drip could make me coherent before 9)

monkeykoder wrote:If everything I remember from my programming classes is correct yes you need to know quite a bit about your programming language but the MOST important part is that you know how to read your reference manuals so you know how to look something up if you get stuck... My first Assembly class went something like this "Here's the instruction set reference for xx microcontroller and here is how you read it now we're going to talk about getting drunk for the rest of class and I'll give you some homework...

Wow, how completely and utterly irrelevant. Also wrong on so many levels I lose count...

JamesM wrote:

monkeykoder wrote:If everything I remember from my programming classes is correct yes you need to know quite a bit about your programming language but the MOST important part is that you know how to read your reference manuals so you know how to look something up if you get stuck... My first Assembly class went something like this "Here's the instruction set reference for xx microcontroller and here is how you read it now we're going to talk about getting drunk for the rest of class and I'll give you some homework...

Wow, how completely and utterly irrelevant. Also wrong on so many levels I lose count...

Well I think I meant it to be relevant... Not exactly sure how it was supposed to be though. I apologize and will remember not to post before 9AM (unless of course it's because I haven't gone to bed yet).