diff options
author | Greg Kroah-Hartman <gregkh@suse.de> | 2005-11-18 13:02:45 -0800 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2005-11-18 13:02:45 -0800 |
commit | af5bb8b5734b69fd3b7763ac3c9d84d1373b0e1e (patch) | |
tree | 0b6eb84065e13a28e094d974978195c38b287bb6 /driver | |
parent | a479304627b2a277d52dfd671b941779d16bc71e (diff) | |
download | patches-af5bb8b5734b69fd3b7763ac3c9d84d1373b0e1e.tar.gz |
moved doc files
Diffstat (limited to 'driver')
-rw-r--r-- | driver/add-howto-to-documentation.patch | 654 | ||||
-rw-r--r-- | driver/add-scm-info-to-maintainers.patch | 148 | ||||
-rw-r--r-- | driver/update-docs-index.patch | 27 |
3 files changed, 829 insertions, 0 deletions
diff --git a/driver/add-howto-to-documentation.patch b/driver/add-howto-to-documentation.patch new file mode 100644 index 0000000000000..1d9b6b11e3d67 --- /dev/null +++ b/driver/add-howto-to-documentation.patch @@ -0,0 +1,654 @@ +From foo@baz.org Fri Nov 18 09:11:43 2005 +Date: Fri, 18 Nov 2005 22:18:50 +0700 +From: Greg Kroah-Hartman <gregkh@suse.de> +Subject: Add HOWTO do kernel development document to the Documentation directory + +Here's a document that describes the process and procedures of how to do Linux +kernel development. It has gone through a number of rounds of review on the +linux-kernel mailing list, and contains contributions and help from Paolo +Ciarrocchi, Randy Dunlap, Gerrit Huizenga, Pat Mochel, Hanna Linder, Kay +Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi +Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop, David +A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard. + + +Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> + + +--- + Documentation/00-INDEX | 2 + Documentation/HOWTO | 618 +++++++++++++++++++++++++++++++++++++++++++++++++ + 2 files changed, 620 insertions(+) + +--- /dev/null ++++ gregkh-2.6/Documentation/HOWTO +@@ -0,0 +1,618 @@ ++HOWTO do Linux kernel development ++--------------------------------- ++ ++This is the be-all, end-all document on this topic. It contains ++instructions on how to become a Linux kernel developer and how to learn ++to work with the Linux kernel development community. It tries to not ++contain anything related to the technical aspects of kernel programming, ++but will help point you in the right direction for that. ++ ++If anything in this document becomes out of date, please send in patches ++to the maintainer of this file, who is listed at the bottom of the ++document. ++ ++ ++Introduction ++------------ ++ ++So, you want to learn how to become a Linux kernel developer? Or you ++have been told by your manager, "Go write a Linux driver for this ++device." This document's goal is to teach you everything you need to ++know to achieve this by describing the process you need to go through, ++and hints on how to work with the community. It will also try to ++explain some of the reasons why the community works like it does. ++ ++The kernel is written mostly in C, with some architecture-dependent ++parts written in assembly. A good understanding of C is required for ++kernel development. Assembly (any architecture) is not required unless ++you plan to do low-level development for that architecture. Though they ++are not a good substitute for a solid C education and/or years of ++experience, the following books are good for, if anything, reference: ++ - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall] ++ - "Practical C Programming" by Steve Oualline [O'Reilly] ++ ++The kernel is written using GNU C and the GNU toolchain. While it ++adheres to the ISO C89 standard, it uses a number of extensions that are ++not featured in the standard. The kernel is a freestanding C ++environment, with no reliance on the standard C library, so some ++portions of the C standard are not supported. Arbitrary long long ++divisions and floating point are not allowed. It can sometimes be ++difficult to understand the assumptions the kernel has on the toolchain ++and the extensions that it uses, and unfortunately there is no ++definitive reference for them. Please check the gcc info pages (`info ++gcc`) for some information on them. ++ ++Please remember that you are trying to learn how to work with the ++existing development community. It is a diverse group of people, with ++high standards for coding, style and procedure. These standards have ++been created over time based on what they have found to work best for ++such a large and geographically dispersed team. Try to learn as much as ++possible about these standards ahead of time, as they are well ++documented; do not expect people to adapt to you or your company's way ++of doing things. ++ ++ ++Legal Issues ++------------ ++ ++The Linux kernel source code is released under the GPL. Please see the ++file, COPYING, in the main directory of the source tree, for details on ++the license. If you have further questions about the license, please ++contact a lawyer, and do not ask on the Linux kernel mailing list. The ++people on the mailing lists are not lawyers, and you should not rely on ++their statements on legal matters. ++ ++For common questions and answers about the GPL, please see: ++ http://www.gnu.org/licenses/gpl-faq.html ++ ++ ++Documentation ++------------ ++ ++The Linux kernel source tree has a large range of documents that are ++invaluable for learning how to interact with the kernel community. When ++new features are added to the kernel, it is recommended that new ++documentation files are also added which explain how to use the feature. ++When a kernel change causes the interface that the kernel exposes to ++userspace to change, it is recommended that you send the information or ++a patch to the manual pages explaining the change to the manual pages ++maintainer at mtk-manpages@gmx.net. ++ ++Here is a list of files that are in the kernel source tree that are ++required reading: ++ README ++ This file gives a short background on the Linux kernel and describes ++ what is necessary to do to configure and build the kernel. People ++ who are new to the kernel should start here. ++ ++ Documentation/Changes ++ This file gives a list of the minimum levels of various software ++ packages that are necessary to build and run the kernel ++ successfully. ++ ++ Documentation/CodingStyle ++ This describes the Linux kernel coding style, and some of the ++ rationale behind it. All new code is expected to follow the ++ guidelines in this document. Most maintainers will only accept ++ patches if these rules are followed, and many people will only ++ review code if it is in the proper style. ++ ++ Documentation/SubmittingPatches ++ Documentation/SubmittingDrivers ++ These files describe in explicit detail how to successfully create ++ and send a patch, including (but not limited to): ++ - Email contents ++ - Email format ++ - Who to send it to ++ Following these rules will not guarantee success (as all patches are ++ subject to scrutiny for content and style), but not following them ++ will almost always prevent it. ++ ++ Other excellent descriptions of how to create patches properly are: ++ "The Perfect Patch" ++ http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt ++ "Linux kernel patch submission format" ++ http://linux.yyz.us/patch-format.html ++ ++ Documentation/stable_api_nonsense.txt ++ This file describes the rationale behind the conscious decision to ++ not have a stable API within the kernel, including things like: ++ - Subsystem shim-layers (for compatibility?) ++ - Driver portability between Operating Systems. ++ - Mitigating rapid change within the kernel source tree (or ++ preventing rapid change) ++ This document is crucial for understanding the Linux development ++ philosophy and is very important for people moving to Linux from ++ development on other Operating Systems. ++ ++ Documentation/SecurityBugs ++ If you feel you have found a security problem in the Linux kernel, ++ please follow the steps in this document to help notify the kernel ++ developers, and help solve the issue. ++ ++ Documentation/ManagementStyle ++ This document describes how Linux kernel maintainers operate and the ++ shared ethos behind their methodologies. This is important reading ++ for anyone new to kernel development (or anyone simply curious about ++ it), as it resolves a lot of common misconceptions and confusion ++ about the unique behavior of kernel maintainers. ++ ++ Documentation/stable_kernel_rules.txt ++ This file describes the rules on how the stable kernel releases ++ happen, and what to do if you want to get a change into one of these ++ releases. ++ ++ Documentation/kernel-docs.txt ++ A list of external documentation that pertains to kernel ++ development. Please consult this list if you do not find what you ++ are looking for within the in-kernel documentation. ++ ++ Documentation/applying-patches.txt ++ A good introduction describing exactly what a patch is and how to ++ apply it to the different development branches of the kernel. ++ ++The kernel also has a large number of documents that can be ++automatically generated from the source code itself. This includes a ++full description of the in-kernel API, and rules on how to handle ++locking properly. The documents will be created in the ++Documentation/DocBook/ directory and can be generated as PDF, ++Postscript, HTML, and man pages by running: ++ make pdfdocs ++ make psdocs ++ make htmldocs ++ make mandocs ++respectively from the main kernel source directory. ++ ++ ++Becoming A Kernel Developer ++--------------------------- ++ ++If you do not know anything about Linux kernel development, you should ++look at the Linux KernelNewbies project: ++ http://kernelnewbies.org ++It consists of a helpful mailing list where you can ask almost any type ++of basic kernel development question (make sure to search the archives ++first, before asking something that has already been answered in the ++past.) It also has an IRC channel that you can use to ask questions in ++real-time, and a lot of helpful documentation that is useful for ++learning about Linux kernel development. ++ ++The website has basic information about code organization, subsystems, ++and current projects (both in-tree and out-of-tree). It also describes ++some basic logistical information, like how to compile a kernel and ++apply a patch. ++ ++If you do not know where you want to start, but you want to look for ++some task to start doing to join into the kernel development community, ++go to the Linux Kernel Janitor's project: ++ http://janitor.kernelnewbies.org/ ++It is a great place to start. It describes a list of relatively simple ++problems that need to be cleaned up and fixed within the Linux kernel ++source tree. Working with the developers in charge of this project, you ++will learn the basics of getting your patch into the Linux kernel tree, ++and possibly be pointed in the direction of what to go work on next, if ++you do not already have an idea. ++ ++If you already have a chunk of code that you want to put into the kernel ++tree, but need some help getting it in the proper form, the ++kernel-mentors project was created to help you out with this. It is a ++mailing list, and can be found at: ++ http://selenic.com/mailman/listinfo/kernel-mentors ++ ++Before making any actual modifications to the Linux kernel code, it is ++imperative to understand how the code in question works. For this ++purpose, nothing is better than reading through it directly (most tricky ++bits are commented well), perhaps even with the help of specialized ++tools. One such tool that is particularly recommended is the Linux ++Cross-Reference project, which is able to present source code in a ++self-referential, indexed webpage format. An excellent up-to-date ++repository of the kernel code may be found at: ++ http://sosdg.org/~coywolf/lxr/ ++ ++ ++The development process ++----------------------- ++ ++Linux kernel development process currently consists of a few different ++main kernel "branches" and lots of different subsystem-specific kernel ++branches. These different branches are: ++ - main 2.6.x kernel tree ++ - 2.6.x.y -stable kernel tree ++ - 2.6.x -git kernel patches ++ - 2.6.x -mm kernel patches ++ - subsystem specific kernel trees and patches ++ ++2.6.x kernel tree ++----------------- ++2.6.x kernels are maintained by Linus Torvalds, and can be found on ++kernel.org in the pub/linux/kernel/v2.6/ directory. Its development ++process is as follows: ++ - As soon as a new kernel is released a two weeks window is open, ++ during this period of time maintainers can submit big diffs to ++ Linus, usually the patches that have already been included in the ++ -mm kernel for a few weeks. The preferred way to submit big changes ++ is using git (the kernel's source management tool, more information ++ can be found at http://git.or.cz/) but plain patches are also just ++ fine. ++ - After two weeks a -rc1 kernel is released it is now possible to push ++ only patches that do not include new features that could affect the ++ stability of the whole kernel. Please note that a whole new driver ++ (or filesystem) might be accepted after -rc1 because there is no ++ risk of causing regressions with such a change as long as the change ++ is self-contained and does not affect areas outside of the code that ++ is being added. git can be used to send patches to Linus after -rc1 ++ is released, but the patches need to also be sent to a public ++ mailing list for review. ++ - A new -rc is released whenever Linus deems the current git tree to ++ be in a reasonably sane state adequate for testing. The goal is to ++ release a new -rc kernel every week. ++ - Process continues until the kernel is considered "ready", the ++ process should last around 6 weeks. ++ ++It is worth mentioning what Andrew Morton wrote on the linux-kernel ++mailing list about kernel releases: ++ "Nobody knows when a kernel will be released, because it's ++ released according to perceived bug status, not according to a ++ preconceived timeline." ++ ++2.6.x.y -stable kernel tree ++--------------------------- ++Kernels with 4 digit versions are -stable kernels. They contain ++relatively small and critical fixes for security problems or significant ++regressions discovered in a given 2.6.x kernel. ++ ++This is the recommended branch for users who want the most recent stable ++kernel and are not interested in helping test development/experimental ++versions. ++ ++If no 2.6.x.y kernel is available, then the highest numbered 2.6.x ++kernel is the current stable kernel. ++ ++2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are ++released almost every other week. ++ ++The file Documentation/stable_kernel_rules.txt in the kernel tree ++documents what kinds of changes are acceptable for the -stable tree, and ++how the release process works. ++ ++2.6.x -git patches ++------------------ ++These are daily snapshots of Linus' kernel tree which are managed in a ++git repository (hence the name.) These patches are usually released ++daily and represent the current state of Linus' tree. They are more ++experimental than -rc kernels since they are generated automatically ++without even a cursory glance to see if they are sane. ++ ++2.6.x -mm kernel patches ++------------------------ ++These are experimental kernel patches released by Andrew Morton. Andrew ++takes all of the different subsystem kernel trees and patches and mushes ++them together, along with a lot of patches that have been plucked from ++the linux-kernel mailing list. This tree serves as a proving ground for ++new features and patches. Once a patch has proved its worth in -mm for ++a while Andrew or the subsystem maintainer pushes it on to Linus for ++inclusion in mainline. ++ ++It is heavily encouraged that all new patches get tested in the -mm tree ++before they are sent to Linus for inclusion in the main kernel tree. ++ ++These kernels are not appropriate for use on systems that are supposed ++to be stable and they are more risky to run than any of the other ++branches. ++ ++If you wish to help out with the kernel development process, please test ++and use these kernel releases and provide feedback to the linux-kernel ++mailing list if you have any problems, and if everything works properly. ++ ++In addition to all the other experimental patches, these kernels usually ++also contain any changes in the mainline -git kernels available at the ++time of release. ++ ++The -mm kernels are not released on a fixed schedule, but usually a few ++-mm kernels are released in between each -rc kernel (1 to 3 is common). ++ ++Subsystem Specific kernel trees and patches ++------------------------------------------- ++A number of the different kernel subsystem developers expose their ++development trees so that others can see what is happening in the ++different areas of the kernel. These trees are pulled into the -mm ++kernel releases as described above. ++ ++Here is a list of some of the different kernel trees available: ++ git trees: ++ - Kbuild development tree, Sam Ravnborg <sam@ravnborg.org> ++ kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git ++ ++ - ACPI development tree, Len Brown <len.brown@intel.com> ++ kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git ++ ++ - Block development tree, Jens Axboe <axboe@suse.de> ++ kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git ++ ++ - DRM development tree, Dave Airlie <airlied@linux.ie> ++ kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git ++ ++ - ia64 development tree, Tony Luck <tony.luck@intel.com> ++ kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git ++ ++ - ieee1394 development tree, Jody McIntyre <scjody@modernduck.com> ++ kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git ++ ++ - infiniband, Roland Dreier <rolandd@cisco.com> ++ kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git ++ ++ - libata, Jeff Garzik <jgarzik@pobox.com> ++ kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git ++ ++ - network drivers, Jeff Garzik <jgarzik@pobox.com> ++ kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git ++ ++ - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net> ++ kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git ++ ++ - SCSI, James Bottomley <James.Bottomley@SteelEye.com> ++ kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git ++ ++ Other git kernel trees can be found listed at http://kernel.org/git ++ ++ quilt trees: ++ - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de> ++ kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ ++ ++ ++Bug Reporting ++------------- ++ ++bugzilla.kernel.org is where the Linux kernel developers track kernel ++bugs. Users are encouraged to report all bugs that they find in this ++tool. For details on how to use the kernel bugzilla, please see: ++ http://test.kernel.org/bugzilla/faq.html ++ ++The file REPORTING-BUGS in the main kernel source directory has a good ++template for how to report a possible kernel bug, and details what kind ++of information is needed by the kernel developers to help track down the ++problem. ++ ++ ++Mailing lists ++------------- ++ ++As some of the above documents describe, the majority of the core kernel ++developers participate on the Linux Kernel Mailing list. Details on how ++to subscribe and unsubscribe from the list can be found at: ++ http://vger.kernel.org/vger-lists.html#linux-kernel ++There are archives of the mailing list on the web in many different ++places. Use a search engine to find these archives. For example: ++ http://dir.gmane.org/gmane.linux.kernel ++It is highly recommended that you search the archives about the topic ++you want to bring up, before you post it to the list. A lot of things ++already discussed in detail are only recorded at the mailing list ++archives. ++ ++Most of the individual kernel subsystems also have their own separate ++mailing list where they do their development efforts. See the ++MAINTAINERS file for a list of what these lists are for the different ++groups. ++ ++Many of the lists are hosted on kernel.org. Information on them can be ++found at: ++ http://vger.kernel.org/vger-lists.html ++ ++Please remember to follow good behavioral habits when using the lists. ++Though a bit cheesy, the following URL has some simple guidelines for ++interacting with the list (or any list): ++ http://www.albion.com/netiquette/ ++ ++If multiple people respond to your mail, the CC: list of recipients may ++get pretty large. Don't remove anybody from the CC: list without a good ++reason, or don't reply only to the list address. Get used to receiving the ++mail twice, one from the sender and the one from the list, and don't try ++to tune that by adding fancy mail-headers, people will not like it. ++ ++Remember to keep the context and the attribution of your replies intact, ++keep the "John Kernelhacker wrote ...:" lines at the top of your reply, and ++add your statements between the individual quoted sections instead of ++writing at the top of the mail. ++ ++If you add patches to your mail, make sure they are plain readable text ++as stated in Documentation/SubmittingPatches. Kernel developers don't ++want to deal with attachments or compressed patches; they may want ++to comment on individual lines of your patch, which works only that way. ++Make sure you use a mail program that does not mangle spaces and tab ++characters. A good first test is to send the mail to yourself and try ++to apply your own patch by yourself. If that doesn't work, get your ++mail program fixed or change it until it works. ++ ++Above all, please remember to show respect to other subscribers. ++ ++ ++Working with the community ++-------------------------- ++ ++The goal of the kernel community is to provide the best possible kernel ++there is. When you submit a patch for acceptance, it will be reviewed ++on its technical merits and those alone. So, what should you be ++expecting? ++ - criticism ++ - comments ++ - requests for change ++ - requests for justification ++ - silence ++ ++Remember, this is part of getting your patch into the kernel. You have ++to be able to take criticism and comments about your patches, evaluate ++them at a technical level and either rework your patches or provide ++clear and concise reasoning as to why those changes should not be made. ++If there are no responses to your posting, wait a few days and try ++again, sometimes things get lost in the huge volume. ++ ++What should you not do? ++ - expect your patch to be accepted without question ++ - become defensive ++ - ignore comments ++ - resubmit the patch without making any of the requested changes ++ ++In a community that is looking for the best technical solution possible, ++there will always be differing opinions on how beneficial a patch is. ++You have to be cooperative, and willing to adapt your idea to fit within ++the kernel. Or at least be willing to prove your idea is worth it. ++Remember, being wrong is acceptable as long as you are willing to work ++toward a solution that is right. ++ ++It is normal that the answers to your first patch might simply be a list ++of a dozen things you should correct. This does _not_ imply that your ++patch will not be accepted, and it is _not_ meant against you ++personally. Simply correct all issues raised against your patch and ++resend it. ++ ++ ++Differences between the kernel community and corporate structures ++----------------------------------------------------------------- ++ ++The kernel community works differently than most traditional corporate ++development environments. Here are a list of things that you can try to ++do to try to avoid problems: ++ Good things to say regarding your proposed changes: ++ - "This solves multiple problems." ++ - "This deletes 2000 lines of code." ++ - "Here is a patch that explains what I am trying to describe." ++ - "I tested it on 5 different architectures..." ++ - "Here is a series of small patches that..." ++ - "This increases performance on typical machines..." ++ ++ Bad things you should avoid saying: ++ - "We did it this way in AIX/ptx/Solaris, so therefore it must be ++ good..." ++ - "I've being doing this for 20 years, so..." ++ - "This is required for my company to make money" ++ - "This is for our Enterprise product line." ++ - "Here is my 1000 page design document that describes my idea" ++ - "I've been working on this for 6 months..." ++ - "Here's a 5000 line patch that..." ++ - "I rewrote all of the current mess, and here it is..." ++ - "I have a deadline, and this patch needs to be applied now." ++ ++Another way the kernel community is different than most traditional ++software engineering work environments is the faceless nature of ++interaction. One benefit of using email and irc as the primary forms of ++communication is the lack of discrimination based on gender or race. ++The Linux kernel work environment is accepting of women and minorities ++because all you are is an email address. The international aspect also ++helps to level the playing field because you can't guess gender based on ++a person's name. A man may be named Andrea and a woman may be named Pat. ++Most women who have worked in the Linux kernel and have expressed an ++opinion have had positive experiences. ++ ++The language barrier can cause problems for some people who are not ++comfortable with English. A good grasp of the language can be needed in ++order to get ideas across properly on mailing lists, so it is ++recommended that you check your emails to make sure they make sense in ++English before sending them. ++ ++ ++Break up your changes ++--------------------- ++ ++The Linux kernel community does not gladly accept large chunks of code ++dropped on it all at once. The changes need to be properly introduced, ++discussed, and broken up into tiny, individual portions. This is almost ++the exact opposite of what companies are used to doing. Your proposal ++should also be introduced very early in the development process, so that ++you can receive feedback on what you are doing. It also lets the ++community feel that you are working with them, and not simply using them ++as a dumping ground for your feature. However, don't send 50 emails at ++one time to a mailing list, your patch series should be smaller than ++that almost all of the time. ++ ++The reasons for breaking things up are the following: ++ ++1) Small patches increase the likelihood that your patches will be ++ applied, since they don't take much time or effort to verify for ++ correctness. A 5 line patch can be applied by a maintainer with ++ barely a second glance. However, a 500 line patch may take hours to ++ review for correctness (the time it takes is exponentially ++ proportional to the size of the patch, or something). ++ ++ Small patches also make it very easy to debug when something goes ++ wrong. It's much easier to back out patches one by one than it is ++ to dissect a very large patch after it's been applied (and broken ++ something). ++ ++2) It's important not only to send small patches, but also to rewrite ++ and simplify (or simply re-order) patches before submitting them. ++ ++Here is an analogy from kernel developer Al Viro: ++ "Think of a teacher grading homework from a math student. The ++ teacher does not want to see the student's trials and errors ++ before they came up with the solution. They want to see the ++ cleanest, most elegant answer. A good student knows this, and ++ would never submit her intermediate work before the final ++ solution." ++ ++ The same is true of kernel development. The maintainers and ++ reviewers do not want to see the thought process behind the ++ solution to the problem one is solving. They want to see a ++ simple and elegant solution." ++ ++It may be challenging to keep the balance between presenting an elegant ++solution and working together with the community and discussing your ++unfinished work. Therefore it is good to get early in the process to ++get feedback to improve your work, but also keep your changes in small ++chunks that they may get already accepted, even when your whole task is ++not ready for inclusion now. ++ ++Also realize that it is not acceptable to send patches for inclusion ++that are unfinished and will be "fixed up later." ++ ++ ++Justify your change ++------------------- ++ ++Along with breaking up your patches, it is very important for you to let ++the Linux community know why they should add this change. New features ++must be justified as being needed and useful. ++ ++ ++Document your change ++-------------------- ++ ++When sending in your patches, pay special attention to what you say in ++the text in your email. This information will become the ChangeLog ++information for the patch, and will be preserved for everyone to see for ++all time. It should describe the patch completely, containing: ++ - why the change is necessary ++ - the overall design approach in the patch ++ - implementation details ++ - testing results ++ ++For more details on what this should all look like, please see the ++ChangeLog section of the document: ++ "The Perfect Patch" ++ http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt ++ ++ ++ ++ ++All of these things are sometimes very hard to do. It can take years to ++perfect these practices (if at all). It's a continuous process of ++improvement that requires a lot of patience and determination. But ++don't give up, it's possible. Many have done it before, and each had to ++start exactly where you are now. ++ ++ ++ ++ ++---------- ++Thanks to Paolo Ciarrocchi who allowed the "Development Process" section ++to be based on text he had written, and to Randy Dunlap and Gerrit ++Huizenga for some of the list of things you should and should not say. ++Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, ++Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi ++Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop, ++David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard for ++their review, comments, and contributions. Without their help, this ++document would not have been possible. ++ ++ ++ ++Maintainer: Greg Kroah-Hartman <greg@kroah.com> +--- gregkh-2.6.orig/Documentation/00-INDEX ++++ gregkh-2.6/Documentation/00-INDEX +@@ -24,6 +24,8 @@ DMA-mapping.txt + - info for PCI drivers using DMA portably across all platforms. + DocBook/ + - directory with DocBook templates etc. for kernel documentation. ++HOWTO ++ - The process and procedures of how to do Linux kernel development. + IO-mapping.txt + - how to access I/O mapped memory from within device drivers. + IPMI.txt diff --git a/driver/add-scm-info-to-maintainers.patch b/driver/add-scm-info-to-maintainers.patch new file mode 100644 index 0000000000000..571aea662f27f --- /dev/null +++ b/driver/add-scm-info-to-maintainers.patch @@ -0,0 +1,148 @@ +From scjody@conscoop.ottawa.on.ca Thu Nov 17 21:32:14 2005 +Date: Fri, 18 Nov 2005 00:40:45 -0500 +From: Jody McIntyre <scjody@steamballoon.com> +To: Greg KH <gregkh@suse.de> +Cc: Jesper Juhl <jesper.juhl@gmail.com>, <greg@kroah.com> +Subject: Add SCM info to MAINTAINERS +Message-ID: <20051118054045.GW4940@conscoop.ottawa.on.ca> +Content-Disposition: inline + + +Add tree information to MAINTAINERS file. + +Signed-off-by: Jody McIntyre <scjody@steamballoon.com> +Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> + +--- + MAINTAINERS | 16 ++++++++++++++++ + 1 file changed, 16 insertions(+) + +--- gregkh-2.6.orig/MAINTAINERS ++++ gregkh-2.6/MAINTAINERS +@@ -58,6 +58,7 @@ P: Person + M: Mail patches to + L: Mailing list that is relevant to this area + W: Web-page with status/info ++T: SCM tree type and URL. Type is one of: git, hg, quilt. + S: Status, one of the following: + + Supported: Someone is actually paid to look after this. +@@ -183,6 +184,7 @@ P: Len Brown + M: len.brown@intel.com + L: acpi-devel@lists.sourceforge.net + W: http://acpi.sourceforge.net/ ++T: git kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git + S: Maintained + + AD1816 SOUND DRIVER +@@ -418,6 +420,7 @@ BLOCK LAYER + P: Jens Axboe + M: axboe@suse.de + L: linux-kernel@vger.kernel.org ++T: git kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git + S: Maintained + + BLUETOOTH SUBSYSTEM +@@ -803,12 +806,14 @@ DRIVER CORE, KOBJECTS, AND SYSFS + P: Greg Kroah-Hartman + M: gregkh@suse.de + L: linux-kernel@vger.kernel.org ++T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ + S: Supported + + DRM DRIVERS + P: David Airlie + M: airlied@linux.ie + L: dri-devel@lists.sourceforge.net ++T: git kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git + S: Maintained + + DSCC4 DRIVER +@@ -1113,6 +1118,7 @@ P: Jean Delvare + M: khali@linux-fr.org + L: lm-sensors@lm-sensors.org + W: http://www.lm-sensors.nu/ ++T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ + S: Maintained + + I2O +@@ -1145,6 +1151,7 @@ P: Tony Luck + M: tony.luck@intel.com + L: linux-ia64@vger.kernel.org + W: http://www.ia64-linux.org/ ++T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git + S: Maintained + + SN-IA64 (Itanium) SUB-PLATFORM +@@ -1212,6 +1219,7 @@ P: Jody McIntyre + M: scjody@steamballoon.com + L: linux1394-devel@lists.sourceforge.net + W: http://www.linux1394.org/ ++T: git kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git + S: Maintained + + IEEE 1394 OHCI DRIVER +@@ -1263,6 +1271,7 @@ P: Hal Rosenstock + M: halr@voltaire.com + L: openib-general@openib.org + W: http://www.openib.org/ ++T: git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git + S: Supported + + INPUT (KEYBOARD, MOUSE, JOYSTICK) DRIVERS +@@ -1436,6 +1445,7 @@ P: Kai Germaschewski + M: kai@germaschewski.name + P: Sam Ravnborg + M: sam@ravnborg.org ++T: git kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git + S: Maintained + + KERNEL JANITORS +@@ -1776,6 +1786,7 @@ M: akpm@osdl.org + P: Jeff Garzik + M: jgarzik@pobox.com + L: netdev@vger.kernel.org ++T: git kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git + S: Maintained + + NETWORKING [GENERAL] +@@ -1953,6 +1964,7 @@ P: Greg Kroah-Hartman + M: gregkh@suse.de + L: linux-kernel@vger.kernel.org + L: linux-pci@atrey.karlin.mff.cuni.cz ++T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ + S: Supported + + PCI HOTPLUG CORE +@@ -1974,6 +1986,7 @@ S: Maintained + PCMCIA SUBSYSTEM + P: Linux PCMCIA Team + L: http://lists.infradead.org/mailman/listinfo/linux-pcmcia ++T: git kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git + S: Maintained + + PCNET32 NETWORK DRIVER +@@ -2183,6 +2196,7 @@ SCSI SUBSYSTEM + P: James E.J. Bottomley + M: James.Bottomley@SteelEye.com + L: linux-scsi@vger.kernel.org ++T: git kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git + S: Maintained + + SCSI TAPE DRIVER +@@ -2222,6 +2236,7 @@ SERIAL ATA (SATA) SUBSYSTEM: + P: Jeff Garzik + M: jgarzik@pobox.com + L: linux-ide@vger.kernel.org ++T: git kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git + S: Supported + + SGI SN-IA64 (Altix) SERIAL CONSOLE DRIVER +@@ -2756,6 +2771,7 @@ M: gregkh@suse.de + L: linux-usb-users@lists.sourceforge.net + L: linux-usb-devel@lists.sourceforge.net + W: http://www.linux-usb.org ++T: quilt kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ + S: Supported + + USB UHCI DRIVER diff --git a/driver/update-docs-index.patch b/driver/update-docs-index.patch new file mode 100644 index 0000000000000..3bcc870cd0a59 --- /dev/null +++ b/driver/update-docs-index.patch @@ -0,0 +1,27 @@ +From foo@baz.org Fri Nov 18 09:11:43 2005 +Date: Fri, 18 Nov 2005 22:18:50 +0700 +From: Greg Kroah-Hartman <gregkh@suse.de> +Subject: update Documentation/00-INDEX + +Update the index file with descriptions of the stable_api_nonsense.txt +and stable_kernel_rules.txt files. + +Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> + +--- + Documentation/00-INDEX | 4 ++++ + 1 file changed, 4 insertions(+) + +--- gregkh-2.6.orig/Documentation/00-INDEX ++++ gregkh-2.6/Documentation/00-INDEX +@@ -258,6 +258,10 @@ specialix.txt + - info on hardware/driver for specialix IO8+ multiport serial card. + spinlocks.txt + - info on using spinlocks to provide exclusive access in kernel. ++stable_api_nonsense.txt ++ - info on why the kernel does not have a stable in-kernel api or abi. ++stable_kernel_rules.txt ++ - rules and procedures for the -stable kernel releases. + stallion.txt + - info on using the Stallion multiport serial driver. + svga.txt |