help for beginner in kernel developpment

[Cchedy]

hi guys!!
i m trying to create my own kernel i have read much tutorial and information about writing a kernel in C++: i don't know where to start and what i have to do first the only think i have released is the loader.asm.
i have read the tutorial about the runtime support in the wiki osdev.
i need someone to help by giving me advice or source from his os, how he began ? which file he start coding? how he realise the runtime(new delete, constructor-destructor).
i m really lost pls helppppp!!! ...

[Cchedy]

hi,
i know i read it from the wiki can you give me how do you start coding your runtime lib ?(sources)
pls help...

[Combuster]

We do not do spoonfeeding.

Seriously, if you can't even follow one of the several tutorials that do exactly what you ask, there's no hope you can write a complete OS on your own. Can you show that you are one of that top 1% of developers that can actually complete the hardest task out there?

[Cchedy]

guys, i m newbie in this world and i m not very good at english because my original languge is frensh ... that's why i cannot understand all the tutorial.
an you give me link to an old project of yours to know how to began?ok?

[Solar]

guys, i m newbie in this world and i m not very good at english because my original languge is frensh ...

About 50% of the people who wrote this material were not native speakers, either...

that's why i cannot understand all the tutorial.

Being able to understand technical documentation written in English is pretty much an elementary requirement for any kind of OS development. You will get only so far without consulting first-hand documentation (e.g. the Intel Manuals), and those only come in English.

And our Wiki is not written in a technical way, but in the easiest-to-understand way that we could manage.

an you give me link to an old project of yours to know how to began?ok?

To exaggerate a bit: You cannot learn from source, you can only copy it.

Sorry. If you cannot make sense out of the material in our Wiki, there is little chance that trying yourself at OS development will bring you (and us, too) anything but frustration.

[Chandra]

guys, i m newbie in this world and i m not very good at english because my original languge is frensh ... that's why i cannot understand all the tutorial.
an you give me link to an old project of yours to know how to began?ok?

Man, you are in real trouble. Almost all the tutorials you find across the net are written in English. On the other hand, copy+paste is not going to work.You actually need to understand what's behind the scene. Sooner or later, you'll realize it.

Best Regards,
Chandra

[Cchedy]

thanks for the explaination guys... i will try to understand.
thanks for the encoragment you are pushing me to code by my self not copying the other code.
here i will try to write what i understand from the tutorial correcte me if i m wrong:
[*]to use the virtual function and global object i have to re-write it by my self: code the runtime lib
[*]same think for new and delete.

[Solar]

Yikes... please take my advice: If you have that much trouble with the information available, for goodness' sake do code in C. That's much easier to get running, and much better documented for kernel work.

[Cchedy]

thanks for your advice

[gravaera]

Yo,

The main problem with your question from my POV is that you're thinking you need to explicitly implement stdlib functions as part of the path toward getting a kernel working. That's not the right way to approach the stdlib thing, imho. Just move into the kernel, and whenever you need a stdlib function, implement that one, and move on. By the time you've finished MM, you'd have, along the way, implemented most of string.c. Then after you're done with the kernel's page level MM, you'll need to implement a heap algo, and at that time, you'll implement malloc/new/free/delete.

But don't think about doing a whole stdlib as a prerequisite bulk project.

--All the best,
gravaera.

[samuelagm]

You know what some few months ago i was in a similar situation, Its better to use C because it was designed to simplify OS development.
Just study some good C tutorials (just a basic knowledge of assembly language is required for now), then get Bran Kendrich's basic kernel with GDT, IDT,Keyboard driver ... etc here -> http://www.osdever.net/bkerndev/Docs/intro.htm, then start bulidng on it, after spending day and night solving the problems you get as you build on it, you become very good, and even start modifying the code to your taste

[gravaera]

then start bulidng on it, after spending day and night solving the problems you get as you build on it, you become very good, and even start modifying the code to your taste

Please stop advising people to do things like that.

[samuelagm]

Please stop advising people to do things like that.

I know it doesn't seem moral, but for a beginner (not an expert) it can aid rapid understanding of a new concept.
Forgive me but i've seen it work!

[Solar]

Then after you're done with the kernel's page level MM, you'll need to implement a heap algo, and at that time, you'll implement malloc/new/free/delete...

...which would leave you in the same trap countless others have walked in before, namely that what a kernel needs to be done and what a user-space application needs to be done when it calls malloc() are two rather different type of fish.

Actually - and I know I am likely biased here seeing how my "project" is a C lib - I think the other way 'round is the much better mental approach: What will my user-space require from my kernel? Because unless you're going for a really esoteric setup, that is pretty much predetermined (system calls for the C library, APIs for graphics, sound, network etc.). You end up with rather well-defined interfaces on both sides of the kernel (the hardware on one side, the user-space API / ABI on the other), and "all you have to do" is to make both ends meet.

[gravaera]

Yo,

Then after you're done with the kernel's page level MM, you'll need to implement a heap algo, and at that time, you'll implement malloc/new/free/delete...

...which would leave you in the same trap countless others have walked in before, namely that what a kernel needs to be done and what a user-space application needs to be done when it calls malloc() are two rather different type of fish.

Actually - and I know I am likely biased here seeing how my "project" is a C lib - I think the other way 'round is the much better mental approach: What will my user-space require from my kernel? Because unless you're going for a really esoteric setup, that is pretty much predetermined (system calls for the C library, APIs for graphics, sound, network etc.). You end up with rather well-defined interfaces on both sides of the kernel (the hardware on one side, the user-space API / ABI on the other), and "all you have to do" is to make both ends meet.

PMM -> VMM -> Heap: PMM and VMM combine to provide page granular allocations. Early on in the kernel bootstrap you won't very much need small allocation sizes. When your MM is up and running, you then set up your heap to provide fine grained allocation, both using object caches and a general heap.

IMHO, there is no confusion there. Also, the kernel's internal standard library functions which it calls for its own use are not exposed to userspace, so they don't help with defining interfaces: you implement internal kernel stdlib functions for the kernel's private use. I'm not sure I fully understood the rest of your post, with sound libs and GFX API libs and all that: a kernel certainly won't be exposing its internal heap's malloc() entry point to userspace.

Also, there really is no trap to fall into in realizing that you've been writing code that copies buffers from one location to another in several places, and that this would be better done with a memcpy() implementation. So you write memcpy, and replace those occurences, then move on. I'm not very sure whether or not I'm the one misunderstanding the OP's question, and in the end it doesn't matter anyway, since both posts just gave suggestions.

--All the best,
gravaera.