If you feel that you can improve the page, then just replace the old stuff with your renewed version. It's a wiki and everything can be restored. You may edit as you wishUnsigned wrote:Hi. The asm goto code in the Interrupt Service Routines article is buggy, and I have better working code which handles not only correct interrupt acknowledge, but also compatibility with multitasking and handling exceptions which push an error code. But I think it would be better to create a separate page for that and substitute the original asm goto code with a little explanation and a link to the new page.
May I modify it?
Wiki Improvement Coordination
- max
- Member
- Posts: 616
- Joined: Mon Mar 05, 2012 11:23 am
- Libera.chat IRC: maxdev
- Location: Germany
- Contact:
Re: Wiki Improvement Coordination
Re: Wiki Improvement Coordination
OK, it's done. Hope it's helpful and you like it.max wrote:If you feel that you can improve the page, then just replace the old stuff with your renewed version. It's a wiki and everything can be restored. You may edit as you wishUnsigned wrote:Hi. The asm goto code in the Interrupt Service Routines article is buggy, and I have better working code which handles not only correct interrupt acknowledge, but also compatibility with multitasking and handling exceptions which push an error code. But I think it would be better to create a separate page for that and substitute the original asm goto code with a little explanation and a link to the new page.
May I modify it?
This comes from my code, which is tested and works. I'm still making the bootloader, so I haven't even started the kernel, but this code supports multitasking and is very easy to use once you understand it. Please tell me if there's something you think that can be improved.
Pages edited:
Interrupt_Service_Routines
Pages created:
ISRs_PIC_And_Multitasking
Re: Wiki Improvement Coordination
The Clang/LLVM page is in need of a rewrite. I managed compile the C bare bones with Clang. It wasn't as easy as I thought it would be. I had to make it output assembly, which I then assembled with the GAS that I compiled with my cross compiler. It's messy, but it works really well (it's fast). Now, if only LLVM could produce NASM or FASM code... then we'd have two completely separate toolchains.
I could take care of that rewrite, if no one else is currently working on one.
I could take care of that rewrite, if no one else is currently working on one.
Re: Wiki Improvement Coordination
I've managed to build bare bone code a lot of times with clang. The only thing I needed to install additionally is GNU binutils (ELF and PE weren't supported by OS X's ld).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
- Alan Kay
- Alan Kay
Re: Wiki Improvement Coordination
Really? I haven't tried it on OS X (I probably should), but on Linux it linked just fine out of the box (Clang on Linux outputs ELF just fine), but it failed to boot. I thought there was something wrong with the object files, and sure enough, when I compiled with -S and assembled it with i686-as, it worked like a charm, but it might be LD, IDK. Speaking of object files, do the LLVM object files just magically link into an ELF binary on OS X, because I kind of doubt that. Or is there some sort of flag for that?Roman wrote:I've managed to build bare bone code a lot of times with clang. The only thing I needed to install additionally is GNU binutils (ELF and PE weren't supported by OS X's ld).
Re: Wiki Improvement Coordination
http://clang.llvm.org/docs/CrossCompilation.html - this is very useful. I've just used the -target flag and -ffreestanding, as I remember.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
- Alan Kay
- Alan Kay
Re: Wiki Improvement Coordination
I used the same flags (and stuff like -nostdlib), but it seems like there are some bugs in Clang on Linux. I'll try and figure out the problem.Roman wrote:http://clang.llvm.org/docs/CrossCompilation.html - this is very useful. I've just used the -target flag and -ffreestanding, as I remember.
IMO the bare bones should provide instructions on how to compile with both. I like Brendan's idea of branching wiki pages. The whole Bare Bones is kind of in need of a rewrite, TBH. The learning curve ("copy-pasting this fully functional bare bones program" to getting past the x86 housekeeping tasks and actually writing a kernel) is pretty insane. It shouldn't hold your hand as much as it does in the beginning, but it shouldn't just leave you without any guidance at all like it does when you're done. Code snippets are fine, as far as I'm concerned, especially for the aforementioned x86-centric tasks, but I say we smooth out the learning curve a little. More focus on x86_64 would be nice as well, because, let's face it, we live in a 64-bit world.
The whole beginner tutorial path would look something like this:
A slightly less pre-chewed, branched C Bare Bones -> A page explaining the basics and some of the quirks of x86 -> (OPTIONAL: Bare Bones, but for x86_64 ->) A less confusing and more in-depth tutorial on interrupts (and maybe keyboard input) for both GCC (asm goto) and Clang (naked functions), but not a complete, working program. -> (OPTIONAL: An in-depth Paging tutorial ->) A concise (and less messy) tutorial on memory management, but this time without any working code, only algorithms and pseudocode -> Micro- vs Monolithic kernels -> (OPTIONAL: A bootloader tutorial ->) The current "What Order Should I Make Things In" page
After that, we should start thinking about things like File Systems, Processes, VGA, Drivers, USB, stuff like that.
The reason everyone and their mother keeps asking about interrupts is because they're messy AF on x86 (well, everything is messy on x86, but that's not my point). I'm not saying we should dumb down the current instructions, I'm just saying we should make them clearer. A year ago, I would've greatly appreciated a page that explained a lot of the quirks of x86, because reading the manual is a pretty traumatizing experience for a beginner.
TL;DR
We shouldn't dumb down the current instructions, but we should make them clearer and more up-to-date. We shouldn't remove all incorrect or messy info, but improve it and reorder the pages in a way that's less confusing to beginners.
Last edited by bbakker on Fri May 08, 2015 8:48 am, edited 1 time in total.
Re: Wiki Improvement Coordination
Almost every operating system developer wants to have networking in their OS (Wouldn't a chat program or a file server in an hobby OS be cool?).
But, everyone doesn't have ethernet or wired Internet. End-users don't want an OS without Wi-Fi. We should have useful information about wireless networking.
And good information about, at least, one popular Wi-Fi device (network card).
But, everyone doesn't have ethernet or wired Internet. End-users don't want an OS without Wi-Fi. We should have useful information about wireless networking.
And good information about, at least, one popular Wi-Fi device (network card).
-
- Member
- Posts: 307
- Joined: Wed Oct 30, 2013 1:57 pm
- Libera.chat IRC: no92
- Location: Germany
- Contact:
Re: Wiki Improvement Coordination
The problem with Wi-Fi is that, at least from what I know, more that just a few cards you'll have to have drivers for in order to cover an acceptable percentage of all PCs. It's not as simple as with the Ethernet cards, where 5 or so cards dominate the PC market. That isn't the main issue though - there's just nobody I know in the hobby osdev community who has implemented Wireless support. There simply isn't nobody around who could even write a article on that.
If you're ready to fight your way through that topic, you can edit the wiki freely. I'm sure a lot of people would appreciate it, including me.
If you're ready to fight your way through that topic, you can edit the wiki freely. I'm sure a lot of people would appreciate it, including me.
-
- Member
- Posts: 119
- Joined: Tue Jan 20, 2015 9:01 am
- Libera.chat IRC: glauxosdever
Re: Wiki Improvement Coordination
Hi,
I also spotted the http://wiki.osdev.org/PCI_IDE_Controller article, which is disputed. Is there a way to fix it, or has to be completely rewritten?
Regards,
glauxosdev
I also spotted the http://wiki.osdev.org/PCI_IDE_Controller article, which is disputed. Is there a way to fix it, or has to be completely rewritten?
Regards,
glauxosdev
Re: Wiki Improvement Coordination
I just extended the paging tutorial (http://wiki.osdev.org/Setting_Up_Paging), could someone check if everything is correct? I think everything is correct but I'm not an expert on paging, the old page just bothered me a lot because paging is quite important, so I tried to improve it.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Wiki Improvement Coordination
My primary concern is that you plagiarised JamesMolloy's code...
Re: Wiki Improvement Coordination
I have used his malloc_int as inspiration, but the rest is my own code. Not sure if you can call it plagiarised by the way, because of how simple the code is, meaning that everybody has a high possibility to come up with it.
- BASICFreak
- Member
- Posts: 284
- Joined: Fri Jan 16, 2009 8:34 pm
- Location: Louisiana, USA
Re: Wiki Improvement Coordination
One function is nearly an identical copy, though the one on JamesMolloy's will work while the one on WiKi will not. (He changed variable names, but didn't change them all)Combuster wrote:My primary concern is that you plagiarised JamesMolloy's code...
But I would dare to say that the frame allocator has no use in paging wiki anyways. It's a whole beast in and of itself - and should have a full wiki dedication, such as it already has Page_Frame_Allocation and Writing_A_Page_Frame_Allocator, linked to the paging wiki - yes they need updating too, but provides much more info than the extremely simplified one that almost EVERY tutorial uses when introducing paging...
My thought is the whole function is completely unnecessary, along with how to find the end of one's kernel, at least in the Setting Up Paging WiKi - both these are covered in better depth by other WiKi pages and should be linked as a prerequisite before continuing the paging WiKi - rather than repeating what has been said countless times.
That's just my $0.02 anyways...
B!
BOS Source Thanks to GitHub
BOS Expanded Commentary
Both under active development!
BOS Expanded Commentary
Both under active development!
Sortie wrote:
- Don't play the role of an operating systems developer, be one.
- Be truly afraid of undefined [behavior].
- Your operating system should be itself, not fight what it is.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Wiki Improvement Coordination
I realized it was Molloy's code because apart from introducing new issues by bad obfuscation, the original bugs were copied as well. You're not getting that past copyright lawyers.
So I suggest you get rid of it and also write that from scratch, if it's even needed to have.
So I suggest you get rid of it and also write that from scratch, if it's even needed to have.