aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/kernel-doc-nano-HOWTO.txt
Commit message (Collapse)AuthorAge
* kernel-doc: allow multi-line declaration purpose descriptionsJohannes Weiner2009-09-18
| | | | | | | | | | | | | | | | | | | | Allow the short description after symbol name and dash in a kernel-doc comment to span multiple lines, e.g. like this: /** * unmap_mapping_range - unmap the portion of all mmaps in the * specified address_space corresponding to the specified * page range in the underlying file. * @mapping: the address space containing mmaps to be unmapped. * ... */ The short description ends with a parameter description, an empty line or the end of the comment block. Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* kernel-doc: restrict syntax for private: and public:Randy Dunlap2009-05-02
| | | | | | | | | | | | | | | | scripts/kernel-doc can (incorrectly) delete struct members that are surrounded by /* ... */ <struct members> /* ... */ if there is a /* private: */ comment in there somewhere also. Fix that by making the "/* private:" only allow whitespace between /* and "private:", not anything/everything in the world. This fixes some erroneous kernel-doc warnings that popped up while processing include/linux/usb/composite.h. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* kernel-doc: preferred ending marker and examplesRandy Dunlap2009-02-11
| | | | | | | | | | Fix kernel-doc-nano-HOWTO.txt to use */ as the ending marker in kernel-doc examples and state that */ is the preferred ending marker. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Reported-by: Robert Love <robert.w.love@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* documentation: how to use DOC: section blocksRandy Dunlap2009-01-06
| | | | | | | | | | | Add info on how to use DOC: sections in kernel-doc. DOC: sections enable the addition of inline source file comments that are general in nature instead of being specific to a function, struct, union, enum, or typedef. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* docs: document how to write @varargs in kernel-docRandy Dunlap2009-01-06
| | | | | | | | | | Add documentation on how to use kernel-doc for function parameters that are "..." (varargs). Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* sched: add kernel doc for the completion, fix kernel-doc-nano-HOWTO.txtKevin Diggs2008-08-26
| | | | | | | | | | This patch adds kernel doc for the completion feature. An error in the split-man.pl PERL snippet in kernel-doc-nano-HOWTO.txt is also fixed. Signed-off-by: Kevin Diggs <kevdig@hypersurf.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* doc: document the kernel-doc conventions for kernel hackersPaul Jackson2008-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | Provide documentation of the kernel-doc documentation conventions oriented to kernel hackers. Since I figure that there will be more people reading this kernel-doc-nano-HOWTO.txt file who are kernel developers focused on the rest of the kernel, than there will be readers of this file who are documentation developers extracting that embedded kernel-doc documentation, I have taken the liberty of making the new section added here: How to format kernel-doc comments the first section of the kernel-doc-nano-HOWTO.txt file. This first section is intended to introduce, motivate and provide basic usage of the kernel-doc mechanism for kernel hackers developing other portions of the kernel. Signed-off-by: Paul Jackson <pj@sgi.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] Discuss a couple common errors in kernel-doc usage.Robert P. J. Day2007-02-11
| | | | | | | | | Explain a couple of the most common errors in kernel-doc usage. Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] kernel-doc: allow a little whitespaceRandy Dunlap2007-02-11
| | | | | | | | | | | | | In kernel-doc syntax, be a little flexible: allow whitespace between a function parameter name and the colon that must follow it, such as: @pdev : PCI device to unplug (This allows lots of megaraid kernel-doc to work without tons of editing.) Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] update some docbook commentsRandy Dunlap2006-11-03
| | | | | | | | | | | Correct a few comments in kernel-doc Doc and source files. (akpm: note: the patch removes a non-ascii character and might have to be applied by hand..) Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Doc/kernel-doc: add more usage infoRandy Dunlap2006-02-01
| | | | | | | | | | | | | | - Add info that structs, unions, enums, and typedefs are supported. - Add doc about "private:" and "public:" tags for struct fields. - Fix some typos. - Remove some trailing whitespace. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!