Kernel uploaded to GitHub
-
I've been using GitHub for my kernel for about 6 months now, and I'm quite happy with it. However, I made a massive error when I was reinstalling Cygwin, git, ssh and such in that I created a commit before setting up my name. Git thoughtfully decided to use my computer name, which wasn't what I wanted. While I was trying to fix that, I made a bigger mess. I've also gained a newfound hatred of vim. To fix all that, I created a new repository and re-uploaded my code. There isn't as much there as I would like, and there are still a few glitches in it, (scalability of my application of message passing being my biggest concern) but it may prove helpful to anybody who wants to see how a microkernel bootstraps itself and begins to jump into a stable environment. Link: GitHub repository (C++) I'll be committing quasi-regularly, but my main work is on porting a functional C library, (Newlib) so there may be unexplained tweaks as I discover issues. Assuming a sane compiler setup, it should work, but I've only tested on Bochs, where the bootstrap initialises the FPU, sets up a timer and jumps into a loop. If I find the time, I'll upload the system call interface (which is as yet incomplete). Hopefully my programming style isn't too off-putting; I didn't exactly write it to function as tutorial code, so there might be a few parts which have somewhat terser comments, or aren't commented at all. It's still a work in progress, and some things may be stubbed or buggy. Enjoy, and good luck.
OSDev :)
-
I've been using GitHub for my kernel for about 6 months now, and I'm quite happy with it. However, I made a massive error when I was reinstalling Cygwin, git, ssh and such in that I created a commit before setting up my name. Git thoughtfully decided to use my computer name, which wasn't what I wanted. While I was trying to fix that, I made a bigger mess. I've also gained a newfound hatred of vim. To fix all that, I created a new repository and re-uploaded my code. There isn't as much there as I would like, and there are still a few glitches in it, (scalability of my application of message passing being my biggest concern) but it may prove helpful to anybody who wants to see how a microkernel bootstraps itself and begins to jump into a stable environment. Link: GitHub repository (C++) I'll be committing quasi-regularly, but my main work is on porting a functional C library, (Newlib) so there may be unexplained tweaks as I discover issues. Assuming a sane compiler setup, it should work, but I've only tested on Bochs, where the bootstrap initialises the FPU, sets up a timer and jumps into a loop. If I find the time, I'll upload the system call interface (which is as yet incomplete). Hopefully my programming style isn't too off-putting; I didn't exactly write it to function as tutorial code, so there might be a few parts which have somewhat terser comments, or aren't commented at all. It's still a work in progress, and some things may be stubbed or buggy. Enjoy, and good luck.
OSDev :)
tell us more about your kernal project Bryce
MCAD --- To paraphrase Fred Dagg - the views expressed in this post are bloody good ones. --
Publitor, making Pubmed easy. http://www.sohocode.com/publitorOur kids books :The Snot Goblin, and Book 2 - the Snotgoblin and Fluff
-
I've been using GitHub for my kernel for about 6 months now, and I'm quite happy with it. However, I made a massive error when I was reinstalling Cygwin, git, ssh and such in that I created a commit before setting up my name. Git thoughtfully decided to use my computer name, which wasn't what I wanted. While I was trying to fix that, I made a bigger mess. I've also gained a newfound hatred of vim. To fix all that, I created a new repository and re-uploaded my code. There isn't as much there as I would like, and there are still a few glitches in it, (scalability of my application of message passing being my biggest concern) but it may prove helpful to anybody who wants to see how a microkernel bootstraps itself and begins to jump into a stable environment. Link: GitHub repository (C++) I'll be committing quasi-regularly, but my main work is on porting a functional C library, (Newlib) so there may be unexplained tweaks as I discover issues. Assuming a sane compiler setup, it should work, but I've only tested on Bochs, where the bootstrap initialises the FPU, sets up a timer and jumps into a loop. If I find the time, I'll upload the system call interface (which is as yet incomplete). Hopefully my programming style isn't too off-putting; I didn't exactly write it to function as tutorial code, so there might be a few parts which have somewhat terser comments, or aren't commented at all. It's still a work in progress, and some things may be stubbed or buggy. Enjoy, and good luck.
OSDev :)
Is it more like Hogan or more like Klink?
-
Is it more like Hogan or more like Klink?
PIEBALDconsult wrote:
Is it more like Hogan or more like Klink?
Wow, that brings back memories. Marc
-
tell us more about your kernal project Bryce
MCAD --- To paraphrase Fred Dagg - the views expressed in this post are bloody good ones. --
Publitor, making Pubmed easy. http://www.sohocode.com/publitorOur kids books :The Snot Goblin, and Book 2 - the Snotgoblin and Fluff
His signature has link to the articles. http://www.codeproject.com/script/Articles/MemberArticles.aspx?amid=3452840[^] -Saurabh
-
tell us more about your kernal project Bryce
MCAD --- To paraphrase Fred Dagg - the views expressed in this post are bloody good ones. --
Publitor, making Pubmed easy. http://www.sohocode.com/publitorOur kids books :The Snot Goblin, and Book 2 - the Snotgoblin and Fluff
It's a microkernel, with some driver management inside the kernel. You can find a little more information about it on the Wiki pages which seem to be attached to the repository. The scheduler uses a lottery-based algorithm, but the random number generation uses FPU-based instructions and I don't like the software FPU emulation. They appear to return 0 until the FPU is initialised, so I load the bootstrap and execute it as the only process; it doesn't get scheduled out, until it initialises the FPU. IPC is exclusively message passing based for now, and I can copy across address spaces quite efficiently, without the need for kernel buffers. I use ELF as the executable format, simply because that's the one I understand the most (dynamic linking, relocations, etc.) My system calls weren't designed to be POSIX-compliant, but are relatively compatible. I still don't see the point of
fork(), considering it's almost always followed byexec()or used to create a new process for incoming connections. My kernel has threads for that. However, a process can be loaded with an array of blocks which outline the contents of its address space, and a custom state. Given a little tweaking, that can work as a functioningfork()Virtual memory uses 4KiB pages for maximum compatibility with x86, and because I want a two-layer paging system so that I can keep my kernel heap consistent. At the moment, driver management isn't very secure. A driver is a process with added privileges. A process can become a driver through a simple BecomeDriver system call, passing a few details about the IRQ it needs. I'd like in future to add support for multiple IRQs, and more finely-grained port IO - at the moment a driver can access any port. I don't want this. All processes (including system and drivers) run in ring 3, so they can't freeze the system in two opcodes. Processes communicate and get access to services which aren't important to the kernel by using IPC, after retrieving the list of running processes from the kernel (there's also a fairly large amount of information which can be retrieved. I added a flags DWORD so the process doesn't get any irrelevant information.)OSDev :)