mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-12-01 08:04:22 +08:00
9db370de27
Commit 31b24bee33 ("docs: add a warning to submitting-drivers.rst")
in October 2016 already warns "This (...) should maybe just be deleted,
but I'm not quite ready to do that yet".
Maybe, six years ago, we were not ready but let us remove old content
for the better now and structure and maintain less content in the kernel
documentation with a better result.
Drop this already outdated document and adjust all textual references.
Here is an argument why deleting the content will not remove any useful
information to the existing kernel documentation, individually broken down
for each section.
Section "Allocating Device Numbers" refers to https://www.lanana.org/, and
then refers to Documentation/admin-guide/devices.rst.
However, the devices.rst clearly states:
"The version of this document at lanana.org is no longer maintained."
Everything needed for submitting drivers is already stated in devices.rst
and the reference to https://www.lanana.org/ is outdated, and should be
just deleted.
Section "Who To Submit Drivers To" is all about Linux 2.0 - 2.6, before
the new release version scheme; the mentioned developers are still around,
but actually not the first developers to contact anymore.
Section "What Criteria Determine Acceptance" has a few bullet points:
Licensing and Copyright is well-covered in process/kernel-license.rst.
Interfaces, Code, Portability, Clarity state some obvious things about
ensuring kernel code quality.
Control suggests to add a MAINTAINERS entry, which is already mentioned in
6.Followthrough.rst: "... added yourself to the MAINTAINERS file..."
PM support states a bit about implementing and testing power management of
a driver, it remains an open question where to place that in the process
documents. Driver developers interested in power management will find the
corresponding part on power management in the kernel documentation anyway.
In section "What Criteria Do Not Determine Acceptance", the points Vendor
and Author states something basic consequence of the kernel being an
open-source community software development. Probably no need to mention it
nowadays.
Section "Resources" lists resources that are also mentioned elsewhere more
central.
- Linux kernel tree and mailing list is mentioned in many places.
- https://lwn.net/Kernel/LDD3/ is mentioned in
Documentation/process/kernel-docs.rst.
- https://lwn.net/ is mentioned in:
- Documentation/process/8.Conclusion.rst
- Documentation/process/kernel-docs.rst
- https://kernelnewbies.org/ is mentioned in:
- Documentation/process/8.Conclusion.rst
- Documentation/process/kernel-docs.rst
- http://www.linux-usb.org/ is mentioned in
Documentation/driver-api/usb/usb.rst
- https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf
is mentioned in Documentation/process/kernel-docs.rst
- https://kernelnewbies.org/KernelJanitors is mentioned in
Documentation/process/howto.rst
- https://git-scm.com/ is mentioned in
- Documentation/process/2.Process.rst
- Documentation/process/7.AdvancedTopics.rst
- Documentation/process/howto.rst
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20220704122537.3407-7-lukas.bulwahn@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
74 lines
3.0 KiB
ReStructuredText
74 lines
3.0 KiB
ReStructuredText
.. _development_conclusion:
|
|
|
|
For more information
|
|
====================
|
|
|
|
There are numerous sources of information on Linux kernel development and
|
|
related topics. First among those will always be the Documentation
|
|
directory found in the kernel source distribution. Start with the
|
|
top-level :ref:`process/howto.rst <process_howto>`; also read
|
|
:ref:`process/submitting-patches.rst <submittingpatches>`. Many internal
|
|
kernel APIs are documented using the kerneldoc mechanism; "make htmldocs"
|
|
or "make pdfdocs" can be used to generate those documents in HTML or PDF
|
|
format (though the version of TeX shipped by some distributions runs into
|
|
internal limits and fails to process the documents properly).
|
|
|
|
Various web sites discuss kernel development at all levels of detail. Your
|
|
author would like to humbly suggest https://lwn.net/ as a source;
|
|
information on many specific kernel topics can be found via the LWN kernel
|
|
index at:
|
|
|
|
https://lwn.net/Kernel/Index/
|
|
|
|
Beyond that, a valuable resource for kernel developers is:
|
|
|
|
https://kernelnewbies.org/
|
|
|
|
And, of course, one should not forget https://kernel.org/, the definitive
|
|
location for kernel release information.
|
|
|
|
There are a number of books on kernel development:
|
|
|
|
Linux Device Drivers, 3rd Edition (Jonathan Corbet, Alessandro
|
|
Rubini, and Greg Kroah-Hartman). Online at
|
|
https://lwn.net/Kernel/LDD3/.
|
|
|
|
Linux Kernel Development (Robert Love).
|
|
|
|
Understanding the Linux Kernel (Daniel Bovet and Marco Cesati).
|
|
|
|
All of these books suffer from a common fault, though: they tend to be
|
|
somewhat obsolete by the time they hit the shelves, and they have been on
|
|
the shelves for a while now. Still, there is quite a bit of good
|
|
information to be found there.
|
|
|
|
Documentation for git can be found at:
|
|
|
|
https://www.kernel.org/pub/software/scm/git/docs/
|
|
|
|
https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
|
|
|
|
|
|
Conclusion
|
|
==========
|
|
|
|
Congratulations to anybody who has made it through this long-winded
|
|
document. Hopefully it has provided a helpful understanding of how the
|
|
Linux kernel is developed and how you can participate in that process.
|
|
|
|
In the end, it's the participation that matters. Any open source software
|
|
project is no more than the sum of what its contributors put into it. The
|
|
Linux kernel has progressed as quickly and as well as it has because it has
|
|
been helped by an impressively large group of developers, all of whom are
|
|
working to make it better. The kernel is a premier example of what can be
|
|
done when thousands of people work together toward a common goal.
|
|
|
|
The kernel can always benefit from a larger developer base, though. There
|
|
is always more work to do. But, just as importantly, most other
|
|
participants in the Linux ecosystem can benefit through contributing to the
|
|
kernel. Getting code into the mainline is the key to higher code quality,
|
|
lower maintenance and distribution costs, a higher level of influence over
|
|
the direction of kernel development, and more. It is a situation where
|
|
everybody involved wins. Fire up your editor and come join us; you will be
|
|
more than welcome.
|