Page 3 of 3
Posted: Tue Jul 10, 2007 8:10 pm
by pcmattman
Kevin McGuire wrote:If you update the SVN I can commit back to it just the changed files. Then you can revert if problems come up that are not trivial?
svn help revert
Or, applying the changes by hand is not too bad. Only existing files I have modified are link.ld, mem.cc, kernel.cc.
Actually I think I might just make the changes by hand. I have had a lot of trouble with SVN lately... It'd be nice if I could clear out the server and then start over.
Posted: Tue Jul 10, 2007 8:16 pm
by Kevin McGuire
Yeah. You have to be careful with it. They like to keep revisions in case you take your project elsewhere.
[edit]
I looked around. It does not look bad at all, really. Quite clean and nice.
What was Brynet-Inc talking about with the branches? How do I see them if they exist?
Posted: Tue Jul 10, 2007 8:29 pm
by pcmattman
I think he's talking about CVS...
Even so, I do pride myself in trying to be as neat as possible - the only really messy thing is the CPP_Kernel thing, which I needed so as not to need a whole new setup just to work on the C++ version of my kernel.
Edit: by the way, what happens if I don't get a memory map from GRUB?
Edit 2: the code compiled out of the box, but I'm getting invalid opcodes when I try to run processes (although atm, they are more like kernel threads)
Edit 3: Here's why:
Code: Select all
Return value from kmalloc( 100 ): 0x1019
Posted: Tue Jul 10, 2007 8:40 pm
by Kevin McGuire
That memory address,
0x1019, should be valid. I gave the heap functions 10KB of memory since I did not want to modify the code you had there, but that should not be the problem since you would be much higher than 0x1000 if it was.
If you update the SVN repository I will
pull it and play around with it tomorrow if you do not find the bug before then.
Edit: by the way, what happens if I don't get a memory map from GRUB?
If you do not get a memory map from GRUB then replace the
pm_init_with_grub_mmap call with:
pm_init((unsigned long)&__end, (( ( MultiBootHeader->mem_upper + MultiBootHeader->mem_lower ) * 1024 ) - sizeof( MemBlock ) - (uint_t) &end) >> 12);
Pretty much doing exactly like you did for the heap, but for the
pm.cc instead.
void pm_init(unsigned long page, unsigned long count)
Posted: Tue Jul 10, 2007 8:42 pm
by pcmattman
Kevin McGuire wrote:That memory address, 0x1019, should be valid. I gave the heap functions 10KB of memory since I did not want to modify the code you had there, but that should not be the problem since you would be much higher than 0x1000 if it was.
If you update the SVN repository I will pull it and play around with it tomorrow if you do not find the bug before then.
It's wrong because I don't want anything below 1 MB unless I've specifically put it there
Also 10 K may not be enough, but I can change that myself.
Posted: Tue Jul 10, 2007 8:47 pm
by Kevin McGuire
To keep anything from being lower than 1MB do:
pm_set((unsigned long)&__start, ((unsigned long)&__end - (unsigned long)&__start) >> 12 + 1, PM_VALID | PM_USED);
pm_set(0x0, 0x100, PM_VALID | PM_USED);
The last function call prevents anything below 1MB. Those function calls come right before the initialize call.
Posted: Tue Jul 10, 2007 8:50 pm
by pcmattman
Much better
Code: Select all
syscore/pm.cc:pm_set:179:saved cmd in tes (100000,a9,3)
syscore/pm.cc:pm_set:179:saved cmd in tes (0,100,3)
syscore/pm.cc:pm_init_with_grub_mmap:51:Called; mmap_addr:2bde8 mmap_length:78
syscore/pm.cc:pm_init_with_grub_mmap:61:base:0 size:9fc00 type:1
syscore/pm.cc:pm_init_with_grub_mmap:61:base:9fc00 size:400 type:2
syscore/pm.cc:pm_init_with_grub_mmap:61:base:e8000 size:18000 type:2
syscore/pm.cc:pm_init_with_grub_mmap:61:base:100000 size:7f00000 type:1
syscore/pm.cc:pm_init_with_grub_mmap:61:base:fffc0000 size:40000 type:2
syscore/pm.cc:pm_init_with_grub_mmap:72:initialization complete.
syscore/pm.cc:pm_set_flush:169:flushed cmd in tes (100000,a9,3)
syscore/pm.cc:pm_set_flush:169:flushed cmd in tes (0,100,3)
[GDT ] Installing GDT... Done!
[IDT ] Installing IDT... Done!
[INT ] Installing interrupts (ISR/IRQ)... Done!
[CPU0] Executing CPUID... Done!
[TMR ] Installing timer... Done!
[KBD ] Installing keyboard... Done!
[MEM ] Installing memory manager... Done!
Return value from kmalloc( 100 ): 0x1a9019
Posted: Tue Jul 10, 2007 8:52 pm
by Kevin McGuire
Nice.
Posted: Tue Jul 10, 2007 8:54 pm
by pcmattman
Now just have to make it work with my kernel threads...
Once I can get threads working again I'll start working on paging.
Posted: Tue Jul 10, 2007 8:59 pm
by Kevin McGuire
Sounds like a plan. Well. I am about to go to bed. But, do not be afraid to use the bug reports or something and upload changes even if incomplete. I can trudge through incomplete (uncompilable or crashing) builds to help find bugs and such when they exist. It gives me something to do.
I mean its not like you are going to run out of revisions or something. You know a lot of software gets tens or hundreds of thousands of revisions over it's life time. Not to mention most if not all revisions are considered unstable or such as being nightly snapshots of the work.
The releases are what count. Thats when you archive it and upload it for download.
Posted: Tue Jul 10, 2007 11:26 pm
by Brynet-Inc
Hey KcMcGuire, if you were talking about one of my old posts praising SVN.. lol
Branches are quite easy, just unlike CVS.. in SVN "directories/folders" are version controlled..
This is one possible layout of the repository..
/trunk/ -- Mainstream development.. or stable.. depending on how you do things..
/branches/bobsnewcode/ -- User bob could deviate from the main trunk to experiment with something..
/tags/version1.0-release/ -- After trunk is at 1.0 level, it's copied into a tags folder.. and never touched.
/branches/version1.0-stable/ -- A copy of 1.0 release, that contains backports of possible security exploits? after fixed.. it could be tagged like:
/tags/version1.0.1-release/
pcmattman just never created the "trunk/tags/branches" folders
Clearly you can see all the possible ways of doing things, for example above.. after bob was done experimenting and the other developers like the changes, he could merge them back into trunk.. and then delete that branch.
Hopefully I'm explaining this right, feel free too send off a few nasty PM's... rofl..
http://svnbook.red-bean.com/ --Great resource..
Posted: Tue Jul 10, 2007 11:53 pm
by Brynet-Inc
I was just thinking it over.. I'm going to explain SVN a little more..
Please correct me if I'm wrong on this though!..
In SVN, imagine you were "bob" above.. working on a project that's trunk is considerably large, and you wanted to create your branch.. you could "SVN copy" it over into a branch directory which should take a few seconds..
So instead of checking out both trunk and your new branch, there is "SVN switch".. it would essentially allow you to change your "working directory" between branches & trunk quickly via a server side "diff" of the two..
I'm also "fairly" sure, for example if /trunk/README and /branches/bobscode/README are the same.. SVN doesn't keep multiple exact copies.. It just sorta "links" them.. saving space..
It's 2am, so if this doesn't make sense.. I've offically lost it.
Posted: Tue Jul 10, 2007 11:56 pm
by pcmattman
Kevin McGuire wrote:Sounds like a plan. Well. I am about to go to bed. But, do not be afraid to use the bug reports or something and upload changes even if incomplete. I can trudge through incomplete (uncompilable or crashing) builds to help find bugs and such when they exist. It gives me something to do.
I mean its not like you are going to run out of revisions or something. You know a lot of software gets tens or hundreds of thousands of revisions over it's life time. Not to mention most if not all revisions are considered unstable or such as being nightly snapshots of the work.
The releases are what count. Thats when you archive it and upload it for download.
I've added you to ICQ (I think) and MSN
Now I'm trying to get paging to work while also debugging other code - now my FAT32 driver has died for some strange reason... probably has something to do with the new allocation scheme allocation space inside the kernel image.
Posted: Wed Jul 11, 2007 11:48 am
by Kevin McGuire
Brynet-Inc wrote:
I was just thinking it over.. I'm going to explain SVN a little more..
Awesome information. I really appreciate you taking the time to explain that to me, Brynet-Inc. You explained it really well, and not only that but you enlightened a totally dark area for me. I also understand that it likely took many sources of information to mentally compile such a reasonably compact amount of information which in no way resembles the hard work required to acquire the information and present it in completeness. I appreciate the help which was in no way required. I also am very excited to check out the link you provided, thanks.
pcmattman wrote:
I've added you to ICQ (I think) and MSN.
I have added your ICQ number to my client too.