Briefly explain the topic. Similar to how Wikipedia has a short abstract at the top of the page, this section should be informative enough to give the reader an overview of the topic, but short enough to digest in thirty seconds or less. These articles are intended to be reviews for students who already have exposure to these topics. Specific to the run-time stack, knowledge of background fundamentals such as C and x86 programming can be assumed.
A good introduction to the run-time stack would briefly discuss where the stack is in system memory, how the stack is structured, and how functions interact with the stack during run-time.
Likewise, a good introduction would not include specific details on the stack, such as where the frame pointer and stack pointer point and how stacks are set up/torn down. These details should be left for later on in the article.
Check the page source for some extra goodies!
The topic should then be divided into logical subsections. Unless implementation is core to the subject, such as an article on basic mathematical implementations in C, implementation details should be left to the end. For many articles, a logical breakdown may include a description of the topic, a discussion on the motivation of the topic, and implementation details.
In many cases, you may wish to add pictures to support your article. This is not the most intuitive process in DokuWiki, at least at first. When editing the article, there should be a button titled “Add Images and other files (opens in a new window)”. Once you've selected the file on your local machine, be sure to prepend the proper namespaces. In this case, the file will look like “:wiki:other:filename.png”, where “other” corresponds to the topic the article is listed under on the sidebar. This is subject to change.
Once you've uploaded your image, it can be inserted by clicking the image (in its proper namespace) and selecting size, alignment, etc.
These subsections should be much more detailed than the abstract, and there is no particular length restriction. That being said, keep in mind that these articles are not meant to be replacements to the manual, and they should be nowhere near as long. If you find yourself hitting pages and pages of content, maybe you should split your topic into multiple articles instead.
In many cases, you'll find that the subject you're writing on has been discussed elsewhere on the internet. Don't be afraid to link to these sites in your articles. It's doubtful that someone could write a better article on Git than Github has already, but don't be concerned about that. Readers come to Kudeki's Corner because it is convenient and specifically tailored to their needs. If they want to learn more, the article should be able to point them in the right direction.
Please attempt to maintain a similar style throughout all articles. For example, there should be a single top-level header with the name of the article, and all logical subsections should be broken down into second-level headers. Don't be concerned about breaking subsections down even further - see the muxes, demuxes, and decoders article for an example of third-level headers.
GitHub's markdown syntax can be used, although a full list of known incompatibilities can be found at the Markdown Plugin page.
Code examples can be styled with the following syntax:
<code lang |title> some code </code>
.global _start .text _start: # write(1, message, 13) mov $1, %rax # system call 1 is write mov $1, %rdi # file handle 1 is stdout mov $message, %rsi # address of string to output mov $13, %rdx # number of bytes syscall # invoke operating system to do the write # exit(0) mov $60, %rax # system call 60 is exit xor %rdi, %rdi # we want return code 0 syscall # invoke operating system to exit message: .ascii "Hello, world\n"