Re: [PATCH] Document: typo fix in mm.txt
Finally know why I have this wrong understanding according to private discussion. Sorry for the noise -- Sincerely, Cao jin On 01/15/2018 11:36 AM, Cao jin wrote: > Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com> > --- > Documentation/x86/x86_64/mm.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt > index ea91cb61a602..8d09b6e5eb3f 100644 > --- a/Documentation/x86/x86_64/mm.txt > +++ b/Documentation/x86/x86_64/mm.txt > @@ -2,7 +2,7 @@ > Virtual memory map with 4 level page tables: > > - 7fff (=47 bits) user space, different per mm > -hole caused by [47:63] sign extension > +hole caused by [48:63] sign extension > 8000 - 87ff (=43 bits) guard hole, reserved for > hypervisor > 8800 - c7ff (=64 TB) direct mapping of all phys. > memory > c800 - c8ff (=40 bits) hole > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Document: typo fix in mm.txt
Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com> --- Documentation/x86/x86_64/mm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt index ea91cb61a602..8d09b6e5eb3f 100644 --- a/Documentation/x86/x86_64/mm.txt +++ b/Documentation/x86/x86_64/mm.txt @@ -2,7 +2,7 @@ Virtual memory map with 4 level page tables: - 7fff (=47 bits) user space, different per mm -hole caused by [47:63] sign extension +hole caused by [48:63] sign extension 8000 - 87ff (=43 bits) guard hole, reserved for hypervisor 8800 - c7ff (=64 TB) direct mapping of all phys. memory c800 - c8ff (=40 bits) hole -- 2.14.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kbuild doc: a bundle of fixes on makefiles.txt
It does several fixes: 1. move the displaced ld example to its reasonale place. 2. add new example for command gzip. 3. fix 2 number errors. 4. fix format of chapter 7.x, make it looks the same as other chapters. Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com> --- Documentation/kbuild/makefiles.txt | 31 ++- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 329e740..f6f8038 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1108,14 +1108,6 @@ When kbuild executes, the following steps are followed (roughly): ld Link target. Often, LDFLAGS_$@ is used to set specific options to ld. -objcopy - Copy binary. Uses OBJCOPYFLAGS usually specified in - arch/$(ARCH)/Makefile. - OBJCOPYFLAGS_$@ may be used to set additional options. - -gzip - Compress target. Use maximum compression to compress target. - Example: #arch/x86/boot/Makefile LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary @@ -1139,6 +1131,19 @@ When kbuild executes, the following steps are followed (roughly): resulting in the target file being recompiled for no obvious reason. +objcopy + Copy binary. Uses OBJCOPYFLAGS usually specified in + arch/$(ARCH)/Makefile. + OBJCOPYFLAGS_$@ may be used to set additional options. + +gzip + Compress target. Use maximum compression to compress target. + + Example: + #arch/x86/boot/compressed/Makefile + $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE + $(call if_changed,gzip) + dtc Create flattened device tree blob object suitable for linking into vmlinux. Device tree blobs linked into vmlinux are placed @@ -1219,7 +1224,7 @@ When kbuild executes, the following steps are followed (roughly): that may be shared between individual architectures. The recommended approach how to use a generic header file is to list the file in the Kbuild file. - See "7.3 generic-y" for further info on syntax etc. + See "7.2 generic-y" for further info on syntax etc. --- 6.11 Post-link pass @@ -1254,13 +1259,13 @@ A Kbuild file may be defined under arch//include/uapi/asm/ and arch//include/asm/ to list asm files coming from asm-generic. See subsequent chapter for the syntax of the Kbuild file. - --- 7.1 no-export-headers +--- 7.1 no-export-headers no-export-headers is essentially used by include/uapi/linux/Kbuild to avoid exporting specific headers (e.g. kvm.h) on architectures that do not support it. It should be avoided as much as possible. - --- 7.2 generic-y +--- 7.2 generic-y If an architecture uses a verbatim copy of a header from include/asm-generic then this is listed in the file @@ -1287,7 +1292,7 @@ See subsequent chapter for the syntax of the Kbuild file. Example: termios.h #include - --- 7.3 generated-y +--- 7.3 generated-y If an architecture generates other header files alongside generic-y wrappers, generated-y specifies them. @@ -1299,7 +1304,7 @@ See subsequent chapter for the syntax of the Kbuild file. #arch/x86/include/asm/Kbuild generated-y += syscalls_32.h - --- 7.5 mandatory-y +--- 7.4 mandatory-y mandatory-y is essentially used by include/uapi/asm-generic/Kbuild.asm to define the minimum set of headers that must be exported in -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
Hi,
I am stuck in a similar problem recent days by chance.
I am just curious about the purpose of introduction of these *_shipped
file, are they just for user's convenience when user doesn't install the
those tools?
--
Sincerely,
Cao jin
On 08/19/2017 04:49 PM, Masahiro Yamada wrote:
> In Linux build system convention, we do not run tools such as
> flex, bison, gperf during the kernel building. Instead, manage
> generated C files in the repository with _shipped suffixes.
> They are simply shipped (copied) removing the _shipped suffixes
> during the kernel building.
>
> Commit 7373f4f83c71 ("kbuild: add implicit rules for parser generation")
> added a mechanism to regenerate intermediate C files easily.
> The build rules are surrounded with ifdef REGENERATE_PARSERS.
> So, we need to pass REGENERATE_PARSERS=1 from the command line
> when we want to update them.
>
> Here is one question. Is it acceptable to use those rules all the time?
> That is, generate those C files by flex, bison, gperf during the
> kernel building.
>
> This means, the build system depends on more external tools.
>>From the users' point of view, they will need to install
> flex, bison, gperf in order to build the kernel.
>>From the developers' point of view, the advantage is
> we do not need to version-control generated files, i.e. _shipped files
> will be deleted.
>
> I'd like to know if this is acceptable or not.
>
> For example, currently some files are simply shipped (copied)
> when building the kconfig program.
>
> $ make mrproper; make defconfig
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/kconfig/conf.o
> SHIPPED scripts/kconfig/zconf.tab.c
> SHIPPED scripts/kconfig/zconf.lex.c
> SHIPPED scripts/kconfig/zconf.hash.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfig/conf
> *** Default configuration is based on 'x86_64_defconfig'
> #
> # configuration written to .config
> #
>
> With this series, they are created from *real* sources
> (*.y, *.l, *.gperf files).
>
> $ make mrproper; make defconfig
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/kconfig/conf.o
> YACCscripts/kconfig/zconf.tab.c
> LEX scripts/kconfig/zconf.lex.c
> GPERF scripts/kconfig/zconf.hash.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfig/conf
> *** Default configuration is based on 'x86_64_defconfig'
> #
> # configuration written to .config
> #
>
> Note:
> The tool versions in Documentation/process/changes.rst are just
> place-holders for now. We need to figure out the minimal versions
> if we like to switch to this approach.
>
>
>
> Masahiro Yamada (3):
> kbuild: generate *.hash.c during build
> kbuild: generate *.lex.c during build
> kbuild: generate *.tab.c and *.tab.h during build
>
> Documentation/process/changes.rst| 36 +
> scripts/Makefile.lib | 26 +-
> scripts/dtc/Makefile |6 +-
> scripts/dtc/dtc-lexer.lex.c_shipped | 2259 ---
> scripts/dtc/dtc-parser.tab.c_shipped | 2303
> scripts/dtc/dtc-parser.tab.h_shipped | 125 --
> scripts/genksyms/Makefile|4 +-
> scripts/genksyms/keywords.hash.c_shipped | 230 ---
> scripts/genksyms/lex.lex.c_shipped | 2291 ---
> scripts/genksyms/parse.tab.c_shipped | 2394 -
> scripts/genksyms/parse.tab.h_shipped | 119 --
> scripts/kconfig/Makefile |1 +
> scripts/kconfig/zconf.hash.c_shipped | 297
> scripts/kconfig/zconf.lex.c_shipped | 2473
> --
> scripts/kconfig/zconf.tab.c_shipped | 2471 -
> 15 files changed, 53 insertions(+), 14982 deletions(-)
> delete mode 100644 scripts/dtc/dtc-lexer.lex.c_shipped
> delete mode 100644 scripts/dtc/dtc-parser.tab.c_shipped
> delete mode 100644 scripts/dtc/dtc-parser.tab.h_shipped
> delete mode 100644 scripts/genksyms/keywords.hash.c_shipped
> delete mode 100644 scripts/genksyms/lex.lex.c_shipped
> delete mode 100644 scripts/genksyms/parse.tab.c_shipped
> delete mode 100644 scripts/genksyms/parse.tab.h_shipped
> delete mode 100644 scripts/kconfig/zconf.hash.c_shipped
> delete mode 100644 scripts/kconfig/zconf.lex.c_shipped
> delete mode 100644 scripts/kconfig/zconf.tab.c_shipped
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sparse doc: fix reference path
Documentation/sparse.txt has been moved to
Documentation/dev-tools/sparse.rst
Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com>
---
Documentation/translations/zh_CN/sparse.txt | 4 ++--
Makefile| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/translations/zh_CN/sparse.txt
b/Documentation/translations/zh_CN/sparse.txt
index e41dc94..2f72896 100644
--- a/Documentation/translations/zh_CN/sparse.txt
+++ b/Documentation/translations/zh_CN/sparse.txt
@@ -1,4 +1,4 @@
-Chinese translated version of Documentation/sparse.txt
+Chinese translated version of Documentation/dev-tools/sparse.rst
If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem
@@ -8,7 +8,7 @@ or if there is a problem with the translation.
Chinese maintainer: Li Yang <l...@zh-kernel.org>
-
-Documentation/sparse.txt 的中文翻译
+Documentation/dev-tools/sparse.rst 的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
diff --git a/Makefile b/Makefile
index 165cf97..0e66ca4 100644
--- a/Makefile
+++ b/Makefile
@@ -172,8 +172,8 @@ MAKEFLAGS += --no-print-directory
# Use 'make C=2' to enable checking of *all* source files, regardless
# of whether they are re-compiled or not.
#
-# See the file "Documentation/sparse.txt" for more details, including
-# where to get the "sparse" utility.
+# See the file "Documentation/dev-tools/sparse.rst" for more details,
+# including where to get the "sparse" utility.
ifeq ("$(origin C)", "command line")
KBUILD_CHECKSRC = $(C)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pci-error-recovery: doc cleanup
CC MST who touched this file in last commit on it. On 03/22/2017 01:48 PM, Linas Vepstas wrote: > Hi, > > On Tue, Mar 21, 2017 at 9:24 PM, Cao jin <caoj.f...@cn.fujitsu.com> wrote: >> Include whitespace shooting; correction; typo fix; superfluous word >> dropping. > >> >> diff --git a/Documentation/PCI/pci-error-recovery.txt >> b/Documentation/PCI/pci-error-recovery.txt >> index da3b217..0b6bb3e 100644 >> --- a/Documentation/PCI/pci-error-recovery.txt >> +++ b/Documentation/PCI/pci-error-recovery.txt >> >> @@ -231,14 +231,14 @@ proceeds to STEP 4 (Slot Reset) >> STEP 3: Link Reset >> -- >> The platform resets the link. This is a PCI-Express specific step >> -and is done whenever a non-fatal error has been detected that can be >> +and is done whenever a fatal error has been detected that can be >> "solved" by resetting the link. > > First: I thought I saw a patch a few months ago that proposed removing > the link rest step. I don't know if the patch was accepted or not. > Yes, I sent this one and I asked to ignore it. At that time, .link_reset handler still exists, now is gone. > If link resets are still supported, then they can only fix NON-fatal errors: > basically, one resets the link, and only the link; one does NOT reset > either the device driver, nor the device state. The idea is that after a link > reset, communications with the device can immediately resume right > where it left off. (this can be hard in practice, if the driver/firmware > doesn't > know what it was doing when the error occurred. this might be why no one > implements it.) Anyway, the whole point of a link reset is that it is > explicitly > a non-fatal error. > Perhaps you are still talking about link re-training. After last commit on this file, section "Link Reset" seems only focus on PCI-Express. If it is a PCI-Express specific step, then I think the "fatal" & "non-fatal" referred here are in the PCI-Express(AER) territory, and according to the AER driver(function do_recovery()), platform level link reset targeted to fatal error. -- Sincerely, Cao jin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pci-error-recovery: doc cleanup
Include whitespace shooting; correction; typo fix; superfluous word dropping. Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com> --- This patch was sent in last December, which is not quite suitable at that time, because link reset is not clear. Now the section "Link Reset" has been cleaned, submit this patch again. Documentation/PCI/pci-error-recovery.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/PCI/pci-error-recovery.txt b/Documentation/PCI/pci-error-recovery.txt index da3b217..0b6bb3e 100644 --- a/Documentation/PCI/pci-error-recovery.txt +++ b/Documentation/PCI/pci-error-recovery.txt @@ -11,7 +11,7 @@ Many PCI bus controllers are able to detect a variety of hardware PCI errors on the bus, such as parity errors on the data and address -busses, as well as SERR and PERR errors. Some of the more advanced +buses, as well as SERR and PERR errors. Some of the more advanced chipsets are able to deal with these errors; these include PCI-E chipsets, and the PCI-host bridges found on IBM Power4, Power5 and Power6-based pSeries boxes. A typical action taken is to disconnect the affected device, @@ -173,7 +173,7 @@ is STEP 6 (Permanent Failure). >>> a value of 0xff on read, and writes will be dropped. If more than >>> EEH_MAX_FAILS I/O's are attempted to a frozen adapter, EEH >>> assumes that the device driver has gone into an infinite loop ->>> and prints an error to syslog. A reboot is then required to +>>> and prints an error to syslog. A reboot is then required to >>> get the device working again. STEP 2: MMIO Enabled @@ -231,14 +231,14 @@ proceeds to STEP 4 (Slot Reset) STEP 3: Link Reset -- The platform resets the link. This is a PCI-Express specific step -and is done whenever a non-fatal error has been detected that can be +and is done whenever a fatal error has been detected that can be "solved" by resetting the link. STEP 4: Slot Reset -- In response to a return value of PCI_ERS_RESULT_NEED_RESET, the -the platform will perform a slot reset on the requesting PCI device(s). +the platform will perform a slot reset on the requesting PCI device(s). The actual steps taken by a platform to perform a slot reset will be platform-dependent. Upon completion of slot reset, the platform will call the device slot_reset() callback. @@ -258,7 +258,7 @@ configuration registers to initialize to their default conditions. For most PCI devices, a soft reset will be sufficient for recovery. Optional fundamental reset is provided to support a limited number -of PCI Express PCI devices for which a soft reset is not sufficient +of PCI Express devices for which a soft reset is not sufficient for recovery. If the platform supports PCI hotplug, then the reset might be @@ -303,7 +303,7 @@ driver performs device init only from PCI function 0: Same as above. Drivers for PCI Express cards that require a fundamental reset must -set the needs_freset bit in the pci_dev structure in their probe function. +set the needs_freset bit in the pci_dev structure in their probe function. For example, the QLogic qla2xxx driver sets the needs_freset bit for certain PCI card types: -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pcieaer doc: update the link
The original link is empty, replace it. Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com> --- The new link is the only one I can find in kernel.org. Documentation/PCI/pcieaer-howto.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/PCI/pcieaer-howto.txt b/Documentation/PCI/pcieaer-howto.txt index ea8cafba255c..acd06bb8 100644 --- a/Documentation/PCI/pcieaer-howto.txt +++ b/Documentation/PCI/pcieaer-howto.txt @@ -256,7 +256,7 @@ After reboot with new kernel or insert the module, a device file named Then, you need a user space tool named aer-inject, which can be gotten from: -http://www.kernel.org/pub/linux/utils/pci/aer-inject/ +https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/ More information about aer-inject can be found in the document comes with its source code. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pci-error-recover: doc cleanup
Sorry for late. On 12/09/2016 10:37 PM, Jonathan Corbet wrote: > On Fri, 9 Dec 2016 14:37:47 +0800 > Cao jin <caoj.f...@cn.fujitsu.com> wrote: > >> I am little confused too, even not sure if we are talking the same >> *fatal error*, I am talking the fatal error defined in PCI Express spec, >> chapter 6.2.2.2.1: > > Therein lies my original discomfort with the change; it didn't seem to > make sense to talk about recovering from a fatal error. Perhaps making > it "is done whenever a fatal error (as defined in section 6.2.2.2.1) has > been detected that can be "solved" by resetting the link" or something > like that to make it clear how the term is being used? > I find that the .link_reset callback of struct pci_error_handlers isn't called by anyone(if I didn't miss anything), and just a few drivers implement this callback, and their implementation seems meaningless. And the reset_link() provided by aer driver seems is a different thing with .link_reset callback. So I am guessing this patch probably is not quite suitable, and the doc maybe need update totally. -- Sincerely, Cao jin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pci-error-recover: doc cleanup
On 12/08/2016 10:05 PM, Jonathan Corbet wrote: > On Thu, 8 Dec 2016 16:16:14 +0800 > Cao jin <caoj.f...@cn.fujitsu.com> wrote: > >> The platform resets the link, and then calls the link_reset() callback >> on all affected device drivers. This is a PCI-Express specific state >> -and is done whenever a non-fatal error has been detected that can be >> +and is done whenever a fatal error has been detected that can be >> "solved" by resetting the link. This call informs the driver of the > > As far as I can tell, the original text was correct here; why do you > think this change needs to be made? > See do_recovery() in aer core, reset_link() is called only seeing fatal error. -- Sincerely, Cao jin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] hrtimers: doc cleanup
It has: a tense correction(led->leads); a typo(unevitably->inevitably); Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com> --- Documentation/timers/hrtimers.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/timers/hrtimers.txt b/Documentation/timers/hrtimers.txt index ce31f65..492f1af 100644 --- a/Documentation/timers/hrtimers.txt +++ b/Documentation/timers/hrtimers.txt @@ -28,9 +28,9 @@ several reasons why such integration is hard/impossible: - the unpredictable [O(N)] overhead of cascading leads to delays which necessitate a more complex handling of high resolution timers, which - in turn decreases robustness. Such a design still led to rather large + in turn decreases robustness. Such a design still leads to rather large timing inaccuracies. Cascading is a fundamental property of the timer - wheel concept, it cannot be 'designed out' without unevitably + wheel concept, it cannot be 'designed out' without inevitably degrading other portions of the timers.c code in an unacceptable way. - the implementation of the current posix-timer subsystem on top of -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hrtimers: doc cleanup
On 04/21/2016 09:23 PM, Jonathan Corbet wrote: On Thu, 21 Apr 2016 18:25:41 +0800 Cao jin <caoj.f...@cn.fujitsu.com> wrote: This change is incorrect - "unacceptable" is exactly what the writer wanted to say here. *it cannot be 'designed out' without inevitably degrading other portions of the timers.c code in an unacceptable way* equals *it can be 'designed out' ... in an acceptable way*, I think. So, just from semantics, my feeling is, *it cannot be 'designed out' in an acceptable way* is the reason why integration is hard. Am I still wrong? The original author, clearly, was talking about the degradation being unacceptable. It seems clear enough, I don't think that change should be made. Thanks, will remove the change in v2 -- Yours Sincerely, Cao jin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hrtimers: doc cleanup
Hi jon Thanks for your quick respond for my 1st patch here. On 04/21/2016 05:56 PM, Jonathan Corbet wrote: On Thu, 21 Apr 2016 17:09:54 +0800 Cao jin <caoj.f...@cn.fujitsu.com> wrote: - wheel concept, it cannot be 'designed out' without unevitably - degrading other portions of the timers.c code in an unacceptable way. + wheel concept, it cannot be 'designed out' without inevitably + degrading other portions of the timers.c code in an acceptable way. This change is incorrect - "unacceptable" is exactly what the writer wanted to say here. *it cannot be 'designed out' without inevitably degrading other portions of the timers.c code in an unacceptable way* equals *it can be 'designed out' ... in an acceptable way*, I think. So, just from semantics, my feeling is, *it cannot be 'designed out' in an acceptable way* is the reason why integration is hard. Am I still wrong? -- Yours Sincerely, Cao jin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
