12 Sep, 2010

1 commit

  • When you don't use !E or !I but only !F, then it's very easy to miss
    including some functions, structs etc. in documentation. To help
    finding which ones were missed, allow printing out the unused ones as
    warnings.

    For example, using this on mac80211 yields a lot of warnings like this:

    Warning: didn't use docs for DOC: mac80211 workqueue
    Warning: didn't use docs for ieee80211_max_queues
    Warning: didn't use docs for ieee80211_bss_change
    Warning: didn't use docs for ieee80211_bss_conf

    when generating the documentation for it.

    Signed-off-by: Johannes Berg
    Signed-off-by: Randy Dunlap
    Signed-off-by: Linus Torvalds

    Johannes Berg
     

12 Jan, 2010

1 commit

  • Remove comments about function short descriptions not allowed to be on
    multiple lines (that was fixed/changed recently).

    Add comments that function "section header:" names need to be unique per
    function/struct/union/typedef/enum.

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

19 Sep, 2009

1 commit

  • 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
    Signed-off-by: Randy Dunlap
    Signed-off-by: Linus Torvalds

    Johannes Weiner
     

03 May, 2009

1 commit

  • scripts/kernel-doc can (incorrectly) delete struct members that are
    surrounded by /* ... */ /* ... */ 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
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

12 Feb, 2009

1 commit


07 Jan, 2009

2 commits


26 Aug, 2008

1 commit


07 Jun, 2008

1 commit

  • 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
    Acked-by: Randy Dunlap
    Cc: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Jackson
     

12 Feb, 2007

2 commits


04 Nov, 2006

1 commit

  • 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
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

02 Feb, 2006

1 commit

  • - 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
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds