diff options
| -rw-r--r-- | README.patches | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/README.patches b/README.patches index 7052b99a4..2f39f5d52 100644 --- a/README.patches +++ b/README.patches @@ -1,5 +1,5 @@ Mauro Carvalho Chehab <mchehab at infradead dot org> - Updated on 2007 August, 1st + Updated on 2007 September, 6 This file describes the general procedures used by the LinuxTV team (*) and by the v4l-dvb community. @@ -212,7 +212,7 @@ f) Another kernel's practice that is agreed to be good is that a After reviewing a patchset, please send an e-mail indicating that, if possible, with some additional data about the testing, with the tag: Reviewed-by: My Name <myemail@mysite.com> - This is particulary important for Kernel to userspace ABI changes. + This is particularly important for Kernel to userspace ABI changes. g) If the patch also affects other parts of kernel (like Alsa or i2c), it is required that, when submitting upstream, the patch @@ -322,9 +322,9 @@ k) By submitting a patch to the subsystem maintainer, either via email l) "Commit earlier and commit often". This is a common used rule at Kernel. This means that a sooner submission of a patch will mean that a review can happen sooner, and help the develop to address the - comments. This helps to reduce the life-cicle for having a changeset + comments. This helps to reduce the life-cycle for having a changeset committed at kernel at the proper time. It also means that the one - changeset should idally address just one issue. So, mixing different + changeset should ideally address just one issue. So, mixing different things at the same patch should be avoided. 5. Knowing about newer patches committed at master hg repository @@ -397,7 +397,7 @@ picture: Window Once a kernel release is done (for example, 2.6.(x-1) version), a -submission window for the newer features and board additions to thenext +submission window for the newer features and board additions to the next kernel release should start. This means that the subsystem maintainer will use this window to submit the work that were done during 2.6.(x-2) time. @@ -409,7 +409,7 @@ testing. After the submission window, only patches with bug fixes should be sent to mainstream. This means that the subsystem maintainer will separate those patches from the submitted ones for kernel submission during -rc -cycle. Generally, the stabilization proccess (rc kernels) takes from 5 +cycle. Generally, the stabilization process (rc kernels) takes from 5 to 7 weeks. To make life easier for the subsystem maintainer, please add: @@ -564,8 +564,8 @@ g. If it is a newer driver (not yet in one of the development trees), recommended way is not to create a newer directory, but keep the driver into an existing one. - Assumming that the will be V4L+DVB, the better place for it to be is under - /linux/drivers/media/video. Assumming also that the newer driver + Assuming that the will be V4L+DVB, the better place for it to be is under + /linux/drivers/media/video. Assuming also that the newer driver will be called as "newdevice", you need to do: a) add at /linux/drivers/media/video/Kconfig something like: @@ -591,7 +591,7 @@ EXTRA_CFLAGS = -Idrivers/media/video codes. Ideally, a source file should have up to 1000 source code lines. After that, you should consider splitting it into smaller files. - In this case, assumming that the will be V4L+DVB, and that the driver + In this case, assuming that the will be V4L+DVB, and that the driver is called "newdevice", all that is needed to add the newer driver is: a) create a newer dir with your driver, for example: @@ -622,7 +622,7 @@ obj-$(CONFIG_VIDEO_NEWDEVICE) += newdevice/ source "drivers/media/video/newdevice/Kconfig" - After that, you will be able to use v4l-dvb makefile to compile your + After that, you will be able to use v4l-dvb Makefile to compile your driver. With: make help |