1. 16 5月, 2017 1 次提交
  2. 20 11月, 2016 1 次提交
  3. 21 7月, 2016 1 次提交
  4. 15 7月, 2015 1 次提交
  5. 28 5月, 2013 1 次提交
  6. 06 12月, 2012 1 次提交
    • Y
      Kernel-doc: Convention: Use a "Return" section to describe return values · ddf5eabd
      Yacine Belkadi 提交于
      Non-void functions should describe their return values in their kernel-doc
      comments. Currently, some don't, others do in various forms. For example:
         * Return the result.
         * Return: The result.
         * Returns the result.
         * Returns: the result.
         * Return Value: The result.
         * @return: the result.
         * This function returns the result.
         * It will return the result.
      
      Defining a convention would improve consistency of kernel-doc comments. It
      would also help scripts/kernel-doc identify the text describing the return
      value of a function. Thus allowing additional checks on the comments, and
      suitable highlighting in the generated docs (man pages, html, etc).
      
      So, as a convention, use a section named "Return" to describe the return
      value of a function.
      Signed-off-by: NYacine Belkadi <yacine.belkadi.1@gmail.com>
      Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      ddf5eabd
  7. 28 11月, 2012 1 次提交
    • Y
      Kernel-doc: Convention: Use a "Return" section to describe return values · e65fe5a9
      Yacine Belkadi 提交于
      Non-void functions should describe their return values in their kernel-doc
      comments. Currently, some don't, others do in various forms. For example:
         * Return the result.
         * Return: The result.
         * Returns the result.
         * Returns: the result.
         * Return Value: The result.
         * @return: the result.
         * This function returns the result.
         * It will return the result.
      
      Defining a convention would improve consistency of kernel-doc comments. It
      would also help scripts/kernel-doc identify the text describing the return
      value of a function. Thus allowing additional checks on the comments, and
      suitable highlighting in the generated docs (man pages, html, etc).
      
      So, as a convention, use a section named "Return" to describe the return
      value of a function.
      Signed-off-by: NYacine Belkadi <yacine.belkadi.1@gmail.com>
      Signed-off-by: NRob Landley <rob@landley.net>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      e65fe5a9
  8. 12 9月, 2010 1 次提交
  9. 12 1月, 2010 1 次提交
  10. 19 9月, 2009 1 次提交
  11. 03 5月, 2009 1 次提交
  12. 12 2月, 2009 1 次提交
  13. 07 1月, 2009 2 次提交
  14. 26 8月, 2008 1 次提交
  15. 07 6月, 2008 1 次提交
    • P
      doc: document the kernel-doc conventions for kernel hackers · 0842b245
      Paul Jackson 提交于
      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: NPaul Jackson <pj@sgi.com>
      Acked-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0842b245
  16. 12 2月, 2007 2 次提交
  17. 04 11月, 2006 1 次提交
  18. 02 2月, 2006 1 次提交
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4