hi
i am just starting to code a simple OS. there are two ways i think to have my source code architecture.
1. put all the functions and variables in .h files. just include the .h files in the kernel.c. this will eventually generate single .o file [kernel.o]. link and we get the kernel
2. put all function declarations in .h files, and actually write the functions in .c files. the .c files will #include the corresponding .h file [eg. */kernlib/hdd.c will include */kerninc/hdd.h]. this will generate indivisual .o files for each .c file. linking them all with the kernel.o will give kernel.
which one should i follow?
just wondering how to backup the code, and backtrack to previous versions if something goes wrong? should it be saved every day/week in a different directory, probably using "diff"? we are a team of two working on the project [and most probably will only i be working heavily]. does CVS suite my needs?
please help me.
thank you.
Code
Re:Code
Unfortunate timing for another beginner question. 
Do not use your first approach. Any change to any of the files will require a complete recompile.
For backing up sources, use some version control software suited to the task. RCS suffices if you are the only one working on the sources. CVS or Subversion are good choices for concurrent development.
I would suggest you try your hands on some user-space programming first and gather some experience. None of the above questions bodes very well for your OS project...
Do not use your first approach. Any change to any of the files will require a complete recompile.
For backing up sources, use some version control software suited to the task. RCS suffices if you are the only one working on the sources. CVS or Subversion are good choices for concurrent development.
I would suggest you try your hands on some user-space programming first and gather some experience. None of the above questions bodes very well for your OS project...
Every good solution is obvious once you've found it.
-
GLneo
Re:Code
i chose the second on, not saying the first wont work(it is a good idea)but it will be hard to debug and in some versions i like to uninclude ".o's" wend not needed, and as of saving i just make a new directory for each version and upload a zip in to: http://www.savefile.com/filehost/ so if my computer explodes 
-
AR
Re:Code
The first approach is not a good idea, it will yield a massive header file which will be illegible with functions calling each other and operating on shared globals.
Generally you'll divide the program into components and create a seperate header/source file pair for each. This allows you to see more clearly what is happening and follow the flow (as well as having some sense of structure so that other components don't try to operate directly on globals belonging to another component which would create a debugging nightmare with trying to find what changes which global to an invalid value).
Generally you'll divide the program into components and create a seperate header/source file pair for each. This allows you to see more clearly what is happening and follow the flow (as well as having some sense of structure so that other components don't try to operate directly on globals belonging to another component which would create a debugging nightmare with trying to find what changes which global to an invalid value).
-
Guest
Re:Code
hi,
i tried both the techniques.
for the first one [with only headers and one '.c' sources]
(plz correct me if this is wrong or this may be interpreted wrong)
this creates a BIG '.i' file, which actually contains all the preprocessed code which will look very much similar if you concatenate all the contents of all of your '.h' files and the '.c' file at the end. This will (AFAIK) be a better option for the compiler to perform optimizations like inlining etc.
and on the other hand, the 2nd approach will give us:
separate '.i' and eventually '.o' files are linked together. this will force the compiler to emit the 'jump' instructions and will not favour inlining in any way (AFAIK){what about __attribute__ ((always_inline)) of GCC, has anyone tried it?}.
as far as i know, from what i tested on two separate code schemes doing same things, i have seen this drawback of the 2nd approach. as quoted above in some posts, there are it's advantages too.
again, please correct me if i am wrong (as usual)
please verify the above inf. before making your decisions!
i tried both the techniques.
for the first one [with only headers and one '.c' sources]
(plz correct me if this is wrong or this may be interpreted wrong)
this creates a BIG '.i' file, which actually contains all the preprocessed code which will look very much similar if you concatenate all the contents of all of your '.h' files and the '.c' file at the end. This will (AFAIK) be a better option for the compiler to perform optimizations like inlining etc.
and on the other hand, the 2nd approach will give us:
separate '.i' and eventually '.o' files are linked together. this will force the compiler to emit the 'jump' instructions and will not favour inlining in any way (AFAIK){what about __attribute__ ((always_inline)) of GCC, has anyone tried it?}.
as far as i know, from what i tested on two separate code schemes doing same things, i have seen this drawback of the 2nd approach. as quoted above in some posts, there are it's advantages too.
again, please correct me if i am wrong (as usual)
please verify the above inf. before making your decisions!
-
AR
Re:Code
You compile the C file which produces an object file which is then linked into a binary. The first approach will favour inlining but do you want code that is fast but is all but impossible to figure out what's going on or change or fix? Or code that is still fast enough but is easy to follow and maintain?
"#include" is a preprocessor directive, basically all it does is copy the header file into the source file at that point before it is compiled.
You should only inline what actually needs to be inlined for performance purposes, or things that wouldn't make sense having their own functions (eg. IN/OUT Assembly instruction wrappers).
"#include" is a preprocessor directive, basically all it does is copy the header file into the source file at that point before it is compiled.
You should only inline what actually needs to be inlined for performance purposes, or things that wouldn't make sense having their own functions (eg. IN/OUT Assembly instruction wrappers).
-
srg_13
Re:Code
Hi.
When I first started wirting my OS, I put all my functions in the main .c file, (which was a bad idea). It was incredibly hard to find anything. Then I copied the functions into about five or six different .h files (eg. asm.h, kernel.h, keyboard.h). I have kept it like this, but now whenever I add new code, I put it in its own .c file. It is now quite easy to read the code, but if you wish to do the first option, make sure you break all your code into many headers, for the best readibility.
-Stephen
When I first started wirting my OS, I put all my functions in the main .c file, (which was a bad idea). It was incredibly hard to find anything. Then I copied the functions into about five or six different .h files (eg. asm.h, kernel.h, keyboard.h). I have kept it like this, but now whenever I add new code, I put it in its own .c file. It is now quite easy to read the code, but if you wish to do the first option, make sure you break all your code into many headers, for the best readibility.
-Stephen
-
dc0d32
Re:Code
hi,
Consider a situation.
You want to modify or fixup some code in the function 'theXYZFunc()', which belongs to some logical entity XYZ [just like hdd]. now, if you have selected the 1st approach, you go to the includes directory, vi the 'xyz.h' file, and modify the function. on the other hand, if you select the 2nd one, you open the '.c' file and modify the code.
this is what i have to say
1. if we are considering ease of finding something in the code [maybe for the original coder and the followers], it takes almost the same time to locate certain function in a '.c' file as in the '.h' file. [provided that the team has taken due care about the readability, and logically divided everything up in separate headers properly]
2. the maintainance operations done in the '.c' files, can also be done in exactly same way in the '.h' files AFAIK.
3. there should not be any problem in debuging the code [haven't tried it though, but seems simple and doable].
i agree that there will be a lot of time wasted in compiling everything up when a slightest bit in a single '.h' changes. and also, since i am sole developer of my os, i don't know about concurrent programming in a team. i guess while working in a team, the '.h' approach may generate problems. i donno.
are there any other problems? i am not able to figure out why no one has given it a try?
[PSB]
Consider a situation.
You want to modify or fixup some code in the function 'theXYZFunc()', which belongs to some logical entity XYZ [just like hdd]. now, if you have selected the 1st approach, you go to the includes directory, vi the 'xyz.h' file, and modify the function. on the other hand, if you select the 2nd one, you open the '.c' file and modify the code.
this is what i have to say
1. if we are considering ease of finding something in the code [maybe for the original coder and the followers], it takes almost the same time to locate certain function in a '.c' file as in the '.h' file. [provided that the team has taken due care about the readability, and logically divided everything up in separate headers properly]
2. the maintainance operations done in the '.c' files, can also be done in exactly same way in the '.h' files AFAIK.
3. there should not be any problem in debuging the code [haven't tried it though, but seems simple and doable].
i agree that there will be a lot of time wasted in compiling everything up when a slightest bit in a single '.h' changes. and also, since i am sole developer of my os, i don't know about concurrent programming in a team. i guess while working in a team, the '.h' approach may generate problems. i donno.
are there any other problems? i am not able to figure out why no one has given it a try?
[PSB]
-
srg_13
Re:Code
True, but I like the .c files better, because yo can have the mani c file with a few headers, and then the other c files can have their own headers. This lets you organise things more easily, and it makes it much easier to find things, because instead of having a huge .h file, you can put that code in a .c file, and break it up in its headers.
-Stephen
-Stephen