kernel/linux.git/Documentation/kernel-hacking/hacking.rst, branch v7.0-rc7

Documentation: kernel-hacking: Remove :c:func: annotations

2026-01-06T22:15:15+00:00

Remove the useless :c:func: annotations. Suggested-by: Jonathan Corbet Signed-off-by: Thorsten Blum Signed-off-by: Jonathan Corbet Message-ID: <20251222232506.2615-2-thorsten.blum@linux.dev>

Documentation: kernel-hacking: Convert internal links

2026-01-06T22:08:43+00:00

Convert internal cross-references in "Putting Your Stuff in the kernel" section from inline code to internal links. Signed-off-by: Bagas Sanjaya Signed-off-by: Jonathan Corbet Message-ID: <20251223035254.22894-4-bagasdotme@gmail.com>

Documentation: kernel-hacking: Do not italicize EXPORT_SYMBOL{,_GPL}() references

2026-01-06T22:08:43+00:00

Do not italicize EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() references in EXPORT_SYMBOL_NS() and EXPORT_SYMBOL_NS_GPL() subsections. Signed-off-by: Bagas Sanjaya Signed-off-by: Jonathan Corbet Message-ID: <20251223035254.22894-3-bagasdotme@gmail.com>

Documentation: kernel-hacking: Remove current macro annotation

2026-01-06T22:08:43+00:00

Remove unneeded :c:macro: annotation of current macro. Signed-off-by: Bagas Sanjaya Signed-off-by: Jonathan Corbet Message-ID: <20251223035254.22894-2-bagasdotme@gmail.com>

Documentation: kernel-hacking: Remove comma

2025-12-22T21:40:24+00:00

The comma is wrong, remove it. Signed-off-by: Thorsten Blum Acked-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20251219171827.44015-2-thorsten.blum@linux.dev>

docs/licensing: Clarify wording about "GPL" and "Proprietary"

2024-11-22T17:44:25+00:00

There are currently some doubts about out-of-tree kernel modules licensed under GPLv3 and if they are supposed to be able to use symbols exported using EXPORT_SYMBOL_GPL. Clarify that "Proprietary" means anything non-GPL2 even though the license might be an open source license. Also disambiguate "GPL compatible" to "GPLv2 compatible". Signed-off-by: Uwe Kleine-König Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20241115103842.585207-2-ukleinek@kernel.org

Documentation: Fix spelling mistake in hacking.rst

2022-10-24T17:27:51+00:00

Fix `botton half locks` to `bottom half locks`. Signed-off-by: Mushahid Hussain Link: https://lore.kernel.org/r/20221017112026.88324-1-mushi.shar@gmail.com Signed-off-by: Jonathan Corbet

docs: process: remove outdated submitting-drivers.rst

2022-07-14T21:03:57+00:00

Commit 31b24bee3357 ("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 Link: https://lore.kernel.org/r/20220704122537.3407-7-lukas.bulwahn@gmail.com Signed-off-by: Jonathan Corbet

Documentation: kernel-hacking: minor edits for style

2022-04-05T15:53:24+00:00

Rusty's kernel-hacking guides provide important information, however they are written in a narrative style that some readers may interpret as off-putting. Since the goal is to make kernel documentation accessible to as many new developers as possible, it's best to avoid the turns of phrase that require a specific cultural context to properly understand. Signed-off-by: Konstantin Ryabitsev Signed-off-by: Jonathan Corbet

Documentation: in_irq() cleanup

2021-08-24T19:28:23+00:00

Replace the obsolete and ambiguos macro in_irq() with new macro in_hardirq(). Signed-off-by: Changbin Du Link: https://lore.kernel.org/r/20210814014831.53083-1-changbin.du@gmail.com Signed-off-by: Jonathan Corbet