Direct page mapping in bottom-up way will allocate memory from low
address for page structures in a range, which is the *bottom*,
not the *end*.
Signed-off-by: Cao jin
---
arch/x86/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 81519f778830d1ab02274eeaaeab6797fdc4ec52
Gitweb:
https://git.kernel.org/tip/81519f778830d1ab02274eeaaeab6797fdc4ec52
Author:Cao jin
AuthorDate:Thu, 11 Mar 2021 16:39:19 +08:00
Committer
Parameter "cmdline" has no use, drop it.
Signed-off-by: Cao jin
---
init/main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/init/main.c b/init/main.c
index c68d784376ca..621a11ed18fb 100644
--- a/init/main.c
+++ b/init/main.c
@@ -404,7 +404,7 @@ static
Since a13f2ef168cb ("x86/xen: remove 32-bit Xen PV guest support"),
RESERVE_BRK_ARRAY() has no user anymore, let's drop it.
Update related comments too.
Signed-off-by: Cao jin
---
arch/x86/include/asm/setup.h | 5 -
arch/x86/kernel/setup.c | 6 +++---
2 files changed, 3
struct setup_data.len is the length of data field. In case of
SETUP_INDIRECT, it should be sizeof(setup_indirect).
Signed-off-by: Cao jin
---
Documentation/x86/boot.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
Suggested-by: H. Peter Anvin
Signed-off-by: Cao jin
---
for 64-bit protocol, setup data still needs to be mapped, as there is
operation on it in extract_kernel(), like:
sanitize_boot_params(boot_params);
initrd doesn't need to be mapped, which is also what KASLR does in its
On 9/1/20 1:35 PM, H. Peter Anvin wrote:
> If you are going to fix the language...
>
> On 2020-08-31 22:25, Cao jin wrote:
>> Sorry, I mis-copied 2 addresses. make sure they are CCed.
>>
>> On 9/1/20 11:41 AM, Cao jin wrote:
>>> Typo fix & file name update
Sorry, I mis-copied 2 addresses. make sure they are CCed.
On 9/1/20 11:41 AM, Cao jin wrote:
> Typo fix & file name update
>
> Signed-off-by: Cao jin
> ---
> Documentation/x86/boot.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/
Typo fix & file name update
Signed-off-by: Cao jin
---
Documentation/x86/boot.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index 7fafc7ac00d7..c04afec90486 100644
--- a/Documentation/x86/boot.rst
+
BTW, this is reported by kernel test robot , so please help to
add:
Reported-by: kernel test robot
when it got merged.
--
Sincerely,
Cao jin
On 5/1/20 4:25 PM, Cao jin wrote:
> Compilation on i386 complains as following:
>
> util/session.c: In
(B): %ld -> %ld, dst_size %ld : %s\n",
^
Fix them by pairing "%zd" to size_t.
Also revert an unnecessary conversion: "(long)src_size" to plain "src_size"
with conversion specifier "%zd".
Signed-off-by: Cao jin
---
tools/perf/util/session.c |
Sorry, the commit message isn't accurate. v2 coming.
--
Sincerely,
Cao jin
On 5/1/20 4:15 PM, Cao jin wrote:
> Compilation on i386 complains as following:
>
> util/session.c: In function 'perf_session__process_compressed_event':
> util/session.c:91:11: error: format '%ld' expe
s\n",
^
Fix them by pairing "%zd" to size_t.
Signed-off-by: Cao jin
---
tools/perf/util/session.c | 2 +-
tools/perf/util/zstd.c| 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 0b0bfe5
On 9/26/19 2:01 PM, Ingo Molnar wrote:
> * Cao jin wrote:
>
>> The fields marked with (reloc) actually are not dedicated for writing,
>> but communicating info for relocatable kernel with boot loaders. For
>> example:
>>
>>
fix typos for:
elaboarte -> elaborate
architecure -> architecture
compltes -> completes
And, convert the markup :c:func:`foo` to foo() as kernel documentation
toolchain can recognize foo() as a function.
Suggested-by: Mike Rapoport
Signed-off-by: Cao jin
---
mm/memblo
On 9/12/19 6:35 PM, Mike Rapoport wrote:
> On Thu, Sep 12, 2019 at 10:54:09AM +0800, Cao jin wrote:
>> On 9/11/19 10:42 PM, Mike Rapoport wrote:
>>
>> Sure. BTW, do you want convert all the markups too?
>>
>> :c:type:`foo` -> struct foo
>> %FOO
On 9/11/19 10:42 PM, Mike Rapoport wrote:
> On Wed, Sep 11, 2019 at 11:08:56AM +0800, Cao jin wrote:
>> elaboarte -> elaborate
>> architecure -> architecture
>> compltes -> completes
>>
>> Signed-off-by: Cao jin
>> ---
>> mm/memblock.c | 6 +
elaboarte -> elaborate
architecure -> architecture
compltes -> completes
Signed-off-by: Cao jin
---
mm/memblock.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index 7d4f61ae666a..0d0f92003d18 100644
--- a/mm/memblock.c
On 8/28/19 2:42 PM, Borislav Petkov wrote:
> On Wed, Aug 28, 2019 at 02:11:00PM +0800, Cao jin wrote:
>
> For the future:
>
>> Subject: Re: [PATCH] x86/cpufeature: explicit comments for duplicate macro
>
> your subject needs to have a verb and start with a capital lett
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: cbb1133b563a63901cf778220eb17e3ff1425aed
Gitweb:
https://git.kernel.org/tip/cbb1133b563a63901cf778220eb17e3ff1425aed
Author:Cao Jin
AuthorDate:Wed, 28 Aug 2019 14:11:00 +08:00
Committer
Help people to understand the author's intent of apparent duplication of
BUILD_BUG_ON_ZERO(NCAPINTS != n), which is hard to detect by eyes.
CC: Dave Hansen
Suggested-by: Borislav Petkov
Signed-off-by: Cao jin
---
Tried my best to describe it accurately, in case of any inaccuracy, feel
free
m missing a case.
> So, Cao, I wouldn't mind having the gist of that above somewhere around
> there in a comment explicitly.
>
A subtle issue hard to detect by eyes. Sure, on the way.
--
Sincerely,
Cao jin
They are wrappers of BUILD_BUG_ON_ZERO(NCAPINTS != n), which is already
present in corresponding *_MASK_BIT_SET. And fill the missing period in
head comments by the way.
Signed-off-by: Cao jin
---
arch/x86/include/asm/cpufeature.h| 2 --
arch/x86/include/asm/disabled-features.h | 1
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: c84b82dd3e593db217f23c60f7edae02c76a3c4c
Gitweb:
https://git.kernel.org/tip/c84b82dd3e593db217f23c60f7edae02c76a3c4c
Author:Cao jin
AuthorDate:Fri, 09 Aug 2019 19:46:12 +08:00
Committer
Hi,
Wish to know whether the patch make sense.
On 8/9/19 7:46 PM, Cao jin wrote:
> Signed-off-by: Cao jin
> ---
> arch/x86/include/asm/fixmap.h | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/as
Signed-off-by: Cao jin
---
arch/x86/include/asm/fixmap.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 9da8cccdf3fb..0c47aa82e2e2 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm
On 7/22/19 4:53 PM, Thomas Gleixner wrote:
> Cao,
>
> On Fri, 19 Jul 2019, Cao jin wrote:
>
>> Commit e6401c130931 ("x86/irq/64: Split the IRQ stack into its own pages")
>> missed to update one piece of comment as it did to its peer in Xen, which
>> wi
Commit-ID: 385065734cd417b9d7739b2ebb62c960aeb3ccb5
Gitweb: https://git.kernel.org/tip/385065734cd417b9d7739b2ebb62c960aeb3ccb5
Author: Cao jin
AuthorDate: Fri, 19 Jul 2019 16:16:35 +0800
Committer: Thomas Gleixner
CommitDate: Mon, 22 Jul 2019 10:54:27 +0200
x86/irq/64: Update stale
Commit e6401c130931 ("x86/irq/64: Split the IRQ stack into its own pages")
missed to update one piece of comment as it did to its peer in Xen, which
will confuse people who still need to read comment.
A bonus fix to identation in ZO's linker script: spaces -> tab.
Signed-of
drop it from VALID_OPEN_FLAGS.
Signed-off-by: Cao jin
---
include/linux/fcntl.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
index d019df946cb2..8a2ca434be6d 100644
--- a/include/linux/fcntl.h
+++ b/include/linux/fcntl.h
On 2/1/19 4:20 PM, Kees Cook wrote:
> On Fri, Feb 1, 2019 at 6:51 PM Cao jin wrote:
>>
>> comments fix: input_size is ZO image size which just don't count .bss
>> in, but has .text, .data, etc;
>> drop unecessary alignment: minimum is either 512M or output, both a
On 1/4/19 8:04 PM, Cao jin wrote:
> No real code modification, just cleanup:
> 1. remove redundant comments which have already appeared above
> 2. comments improvement:
> "aligned to a 2M boundary"
> -->
> "aligned up to CONFIG_PHYSICAL_ALIGN
On 2/1/19 4:20 PM, Kees Cook wrote:
> On Fri, Feb 1, 2019 at 6:51 PM Cao jin wrote:
>>
>> comments fix: input_size is ZO image size which just don't count .bss
>> in, but has .text, .data, etc;
>> drop unecessary alignment: minimum is either 512M or output, both a
comments fix: input_size is ZO image size which just don't count .bss
in, but has .text, .data, etc;
drop unecessary alignment: minimum is either 512M or output, both are
CONFIG_PHYSICAL_ALIGN aligned(output is aligned in head_32/64.S). But
mention it in earlier comments.
Signed-off-by: Cao jin
Hi,
Is the patch not right?
--
Sincerely,
Cao jin
On 1/4/19 8:04 PM, Cao jin wrote:
> No real code modification, just cleanup:
> 1. remove redundant comments which have already appeared above
> 2. comments improvement:
> "aligned to a 2M boundary"
>
Commit-ID: 0a278662f53159354a0391a17741a20db736256a
Gitweb: https://git.kernel.org/tip/0a278662f53159354a0391a17741a20db736256a
Author: Cao jin
AuthorDate: Wed, 23 Jan 2019 18:00:14 +0800
Committer: Thomas Gleixner
CommitDate: Tue, 29 Jan 2019 22:09:12 +0100
x86/boot: Save several
gdt64 represents the content of GDTR under x86-64, which actually needs
10 bytes only, ".long" & ".word" is superfluous.
Signed-off-by: Cao jin
---
arch/x86/boot/compressed/head_64.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/boot/compressed/he
', needed by
'include/config/kernel.release'. Stop.
Any idea on this problem? Or anyone has ever tried ld 2.20 successfully?
--
Sincerely,
Cao jin
On 1/22/19 9:08 PM, Kirill A. Shutemov wrote:
> On Tue, Jan 22, 2019 at 03:31:25PM +0800, Cao jin wrote:
>> Hi, Kirll,
>>
>>> 2.
>>> Why gdt64 has following definition?:
>>>
>>> gdt64:
>>> .word gdt_end - gdt
>>> .
Hi, Kirll,
On 1/15/19 7:45 PM, Cao jin wrote:
> Hi,
> I have been digging into this file for a while, and I still have 2
> questions unclear, hope to get your help.
>
>
> 2.
> Why gdt64 has following definition?:
>
> gdt64:
> .word gdt_end - gdt
>
On 1/15/19 11:55 PM, Thomas Gleixner wrote:
> On Tue, 15 Jan 2019, Cao jin wrote:
>
>> Hi,
>> I have been digging into this file for a while, and I still have 2
>> questions unclear, hope to get your help.
>>
>> 1.
>> At the entry of startup_64,
_end - gdt
.quad 0
With above modification, it can boot.
--
Sincerely,
Cao jin
On 1/8/19 4:46 PM, Cao jin wrote:
> One more question: in compressed/, for mem*(), it seems we both use the
> macros of boot/string.h, and the functions of compressed/string.c. Is
> that what we want?
>
> compressed/ is compiled with -O2, so it cannot be told by objdump -d,
Hello HPA,
On 1/8/19 4:38 PM, h...@zytor.com wrote:
> On January 7, 2019 12:52:57 AM PST, Cao jin wrote:
>> Hi,
>>
>> On 1/7/19 3:59 PM, h...@zytor.com wrote:
>>> On January 6, 2019 11:40:56 PM PST, Cao jin
>> wrote:
>>>> According to objd
ciate it someone can
leave a hint.
--
Sincerely,
Cao jin
On 1/7/19 3:40 PM, Cao jin wrote:
> According to objdump output of setup, function memset is not used in
> setup code. Currently, all usage of memset in setup come from macro
> definition of string.h.
>
> Signed-off-by: Cao j
Hi,
On 1/7/19 3:59 PM, h...@zytor.com wrote:
> On January 6, 2019 11:40:56 PM PST, Cao jin wrote:
>> According to objdump output of setup, function memset is not used in
>> setup code. Currently, all usage of memset in setup come from macro
>> definition of string.h.
>>
According to objdump output of setup, function memset is not used in
setup code. Currently, all usage of memset in setup come from macro
definition of string.h.
Signed-off-by: Cao jin
---
Compiled and booted under x86_64; compiled under i386.
Questions: now there is 2 definition of memcpy, one
indentation fix in linker script: spaces -> tab
Signed-off-by: Cao jin
---
arch/x86/boot/compressed/head_64.S | 13 +
arch/x86/boot/compressed/vmlinux.lds.S | 4 ++--
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/x86/boot/compressed/head_64.S
b/arch/
a8: ("x86/boot: Reorganize and clean
up the BIOS area reservation code"), still no clue.
--
Sincerely,
Cao jin
On 11/9/18 9:00 PM, Thomas Gleixner wrote:
> Cao,
>
> On Fri, 9 Nov 2018, Cao jin wrote:
>
>> gzip file has 4-byte little-endian file size encoded at the end of file,
>> while all the other compressed kernel file has size_append operation in
>> the Makefile which
On 11/9/18 9:00 PM, Thomas Gleixner wrote:
> Cao,
>
> On Fri, 9 Nov 2018, Cao jin wrote:
>
>> gzip file has 4-byte little-endian file size encoded at the end of file,
>> while all the other compressed kernel file has size_append operation in
>> the Makefile which
gzip file has 4-byte little-endian file size encoded at the end of file,
while all the other compressed kernel file has size_append operation in
the Makefile which also append the 4-byte little-endian file size. There
is no need to do endianness transforming by mkpiggy.
Signed-off-by: Cao jin
gzip file has 4-byte little-endian file size encoded at the end of file,
while all the other compressed kernel file has size_append operation in
the Makefile which also append the 4-byte little-endian file size. There
is no need to do endianness transforming by mkpiggy.
Signed-off-by: Cao jin
On 07/08/2018 10:15 AM, Masahiro Yamada wrote:
> 2018-07-06 17:49 GMT+09:00 Cao jin :
>> Masahiro-san,
>>
>> I am writing some utility for internal kdump test with latest kernel,
>> my purpose is to test the new introduced kernel feature. For automatical
>>
On 07/08/2018 10:15 AM, Masahiro Yamada wrote:
> 2018-07-06 17:49 GMT+09:00 Cao jin :
>> Masahiro-san,
>>
>> I am writing some utility for internal kdump test with latest kernel,
>> my purpose is to test the new introduced kernel feature. For automatical
>>
e in kbuild, so,
Acked-by: Cao jin
--
Sincerely,
Cao jin
> ---
> Documentation/kbuild/kbuild.txt |5 +
> 1 file changed, 5 insertions(+)
>
> --- lnx-418-rc3.orig/Documentation/kbuild/kbuild.txt
> +++ lnx-418-rc3/Documentation/kbuild/kbuild.txt
&g
e in kbuild, so,
Acked-by: Cao jin
--
Sincerely,
Cao jin
> ---
> Documentation/kbuild/kbuild.txt |5 +
> 1 file changed, 5 insertions(+)
>
> --- lnx-418-rc3.orig/Documentation/kbuild/kbuild.txt
> +++ lnx-418-rc3/Documentation/kbuild/kbuild.txt
&g
n olddefconfig.
All these things let me have 2 questions:
1. What would you suggest for my purpose?
2. allyesconfig, allmodconfig, randconfig seems useful for test kbuild,
but what's the purpose of allnoconfig, alldefconfig? In others words,
when people would need allnoconfig, alldefconfig?
--
Sincerely,
Cao jin
n olddefconfig.
All these things let me have 2 questions:
1. What would you suggest for my purpose?
2. allyesconfig, allmodconfig, randconfig seems useful for test kbuild,
but what's the purpose of allnoconfig, alldefconfig? In others words,
when people would need allnoconfig, alldefconfig?
--
Sincerely,
Cao jin
ping?
On 03/05/2018 03:15 PM, Cao jin wrote:
> 1. typo fix: there -> their
> 2. remove superfluous "by"
>
> Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com>
> ---
> arch/x86/tools/relocs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
ping?
On 03/05/2018 03:15 PM, Cao jin wrote:
> 1. typo fix: there -> their
> 2. remove superfluous "by"
>
> Signed-off-by: Cao jin
> ---
> arch/x86/tools/relocs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/
Commit-ID: d6289f36aa7d5893d091a7a0c67eee7798719f03
Gitweb: https://git.kernel.org/tip/d6289f36aa7d5893d091a7a0c67eee7798719f03
Author: Cao jin <caoj.f...@cn.fujitsu.com>
AuthorDate: Fri, 16 Mar 2018 16:49:44 +0800
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat, 31
Commit-ID: d6289f36aa7d5893d091a7a0c67eee7798719f03
Gitweb: https://git.kernel.org/tip/d6289f36aa7d5893d091a7a0c67eee7798719f03
Author: Cao jin
AuthorDate: Fri, 16 Mar 2018 16:49:44 +0800
Committer: Ingo Molnar
CommitDate: Sat, 31 Mar 2018 08:02:07 +0200
x86/build: Don't pass
ping?
On 03/16/2018 04:49 PM, Cao jin wrote:
> Some ..cmd files under arch/x86 report -D__KERNEL__ appears two
> times in the command line, like arch/x86/boot, arch/x86/realmode/rm.
> It is already defined in KBUILD_CPPFLAGS from top Makefile. so it can be
> dropped saftely from the
ping?
On 03/16/2018 04:49 PM, Cao jin wrote:
> Some ..cmd files under arch/x86 report -D__KERNEL__ appears two
> times in the command line, like arch/x86/boot, arch/x86/realmode/rm.
> It is already defined in KBUILD_CPPFLAGS from top Makefile. so it can be
> dropped saftely from the
Thanks very much for you hint!
On 03/21/2018 05:57 PM, Thomas Gleixner wrote:
> On Wed, 21 Mar 2018, Cao jin wrote:
>> On 03/17/2018 06:01 PM, Cao jin wrote:
>>> I find two small questions which confuse me a little.
>>>
>>> 1.
>>> # Check signature a
Thanks very much for you hint!
On 03/21/2018 05:57 PM, Thomas Gleixner wrote:
> On Wed, 21 Mar 2018, Cao jin wrote:
>> On 03/17/2018 06:01 PM, Cao jin wrote:
>>> I find two small questions which confuse me a little.
>>>
>>> 1.
>>> # Check signature a
Dear Maintainers,
Could you help to give a hint?
Thanks in advance.
--
Sincerely,
Cao jin
On 03/17/2018 06:01 PM, Cao jin wrote:
> Hi,
>
> I find two small questions which confuse me a little.
>
> 1.
> # Check signature at end of setup
>cmpl$
Dear Maintainers,
Could you help to give a hint?
Thanks in advance.
--
Sincerely,
Cao jin
On 03/17/2018 06:01 PM, Cao jin wrote:
> Hi,
>
> I find two small questions which confuse me a little.
>
> 1.
> # Check signature at end of setup
>cmpl$
ace the 2nd line with:
movw$_end, %cx
or:
movw$__bss_end+3, %cx
are both fine.
--
Sincerely,
Cao jin
ace the 2nd line with:
movw$_end, %cx
or:
movw$__bss_end+3, %cx
are both fine.
--
Sincerely,
Cao jin
Some ..cmd files under arch/x86 report -D__KERNEL__ appears two
times in the command line, like arch/x86/boot, arch/x86/realmode/rm.
It is already defined in KBUILD_CPPFLAGS from top Makefile. so it can be
dropped saftely from these Makefiles.
Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.
Some ..cmd files under arch/x86 report -D__KERNEL__ appears two
times in the command line, like arch/x86/boot, arch/x86/realmode/rm.
It is already defined in KBUILD_CPPFLAGS from top Makefile. so it can be
dropped saftely from these Makefiles.
Signed-off-by: Cao jin
---
arch/x86/Makefile
The series build successfully on upstream in my: make allyesconfig and
allmodconfig, so,
Tested-by: Cao jin <caoj.f...@cn.fujitsu.com>
--
Sincerely,
Cao jin
On 03/08/2018 09:04 AM, Masahiro Yamada wrote:
>
> 3/5 takes into account '-m' case for multi-used-m.
>
> 2/5 is ne
The series build successfully on upstream in my: make allyesconfig and
allmodconfig, so,
Tested-by: Cao jin
--
Sincerely,
Cao jin
On 03/08/2018 09:04 AM, Masahiro Yamada wrote:
>
> 3/5 takes into account '-m' case for multi-used-m.
>
> 2/5 is necessary beforehand because 3/5
On 03/08/2018 09:05 AM, Masahiro Yamada wrote:
> Just a cosmetic change to put related code close together.
>
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
Reviewed-by: Cao jin <caoj.f...@cn.fujitsu.com>
--
Sincerely,
Cao jin
On 03/08/2018 09:05 AM, Masahiro Yamada wrote:
> Just a cosmetic change to put related code close together.
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Cao jin
--
Sincerely,
Cao jin
-multi-objs-y := $(addprefix $(obj)/,$(multi-objs-y))
> -multi-objs-m := $(addprefix $(obj)/,$(multi-objs-m))
> subdir-ym:= $(addprefix $(obj)/,$(subdir-ym))
>
> # These flags are needed for modversions and compiling, so we define them
> here
>
multi-objs-y/m seems only exist for rules above with target-specific
variable assignment. A great simplification, So
Reviewed-by: Cao jin <caoj.f...@cn.fujitsu.com>
--
Sincerely,
Cao jin
j)/,$(multi-objs-y))
> -multi-objs-m := $(addprefix $(obj)/,$(multi-objs-m))
> subdir-ym:= $(addprefix $(obj)/,$(subdir-ym))
>
> # These flags are needed for modversions and compiling, so we define them
> here
>
multi-objs-y/m seems only exist for rules above with target-specific
variable assignment. A great simplification, So
Reviewed-by: Cao jin
--
Sincerely,
Cao jin
Masahiro-san
On 03/08/2018 06:21 PM, Masahiro Yamada wrote:
> 2018-03-08 19:11 GMT+09:00 Cao jin <caoj.f...@cn.fujitsu.com>:
>>
>>
>> On 03/08/2018 09:05 AM, Masahiro Yamada wrote:
>>> Currently, KBUILD_MODNAME is defined only when $(modname) contains
>&g
Masahiro-san
On 03/08/2018 06:21 PM, Masahiro Yamada wrote:
> 2018-03-08 19:11 GMT+09:00 Cao jin :
>>
>>
>> On 03/08/2018 09:05 AM, Masahiro Yamada wrote:
>>> Currently, KBUILD_MODNAME is defined only when $(modname) contains
>>> just one word. If an
ul for describing the dependency of composite objects
> # Usage:
>
A subtle catch! And in my test, a debug line
$(info $@ = $*)
in rule:
$(obj)/%.o: $(src)/%.c xxx
does tell me it is correct. So,
Reviewed-by: Cao jin <caoj.f...@cn.fujitsu.com>
--
Sincerely,
Cao jin
site objects
> # Usage:
>
A subtle catch! And in my test, a debug line
$(info $@ = $*)
in rule:
$(obj)/%.o: $(src)/%.c xxx
does tell me it is correct. So,
Reviewed-by: Cao jin
--
Sincerely,
Cao jin
dname))
>
I guess there is comment also need to be modified above this code hunk:
Note: Files that end up in two or more modules are compiled without the
KBUILD_MODNAME definition. The reason is that any made-up name
would differ in different configs.
--
Sincerely,
Cao jin
lso need to be modified above this code hunk:
Note: Files that end up in two or more modules are compiled without the
KBUILD_MODNAME definition. The reason is that any made-up name
would differ in different configs.
--
Sincerely,
Cao jin
1. typo fix: there -> their
2. remove superfluous "by"
Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com>
---
arch/x86/tools/relocs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 5d73c443e778..
1. typo fix: there -> their
2. remove superfluous "by"
Signed-off-by: Cao jin
---
arch/x86/tools/relocs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 5d73c443e778..fcf3fad01b08 100644
--- a/a
Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com>
---
I guess this belongs to kbuild though get_maintainer.pl doesn't tell me that.
scripts/kallsyms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 9ee9bf7fd1a2..657926
Signed-off-by: Cao jin
---
I guess this belongs to kbuild though get_maintainer.pl doesn't tell me that.
scripts/kallsyms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 9ee9bf7fd1a2..65792650c630 100644
--- a/scripts
GCC_PLUGINS_CFLAGS is already in the environment, so it is superfluous
to add it in commanline of final build of init/
Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com>
---
This is only tested with Randomizing Structure Layout plugin. The test
method is not so grace but I think it can
GCC_PLUGINS_CFLAGS is already in the environment, so it is superfluous
to add it in commanline of final build of init/
Signed-off-by: Cao jin
---
This is only tested with Randomizing Structure Layout plugin. The test
method is not so grace but I think it can prove the correctness of this
patch
Sorry for late.
On 02/14/2018 07:31 PM, Masahiro Yamada wrote:
> 2018-02-13 16:08 GMT+09:00 Cao jin <caoj.f...@cn.fujitsu.com>:
>
>> BTW, I still have 2 questions.
>>
>> 1. In final build, why need
>>
>>GCC_PLUGINS_CFLAGS="${GCC_PLUGINS_CFLAGS}&
Sorry for late.
On 02/14/2018 07:31 PM, Masahiro Yamada wrote:
> 2018-02-13 16:08 GMT+09:00 Cao jin :
>
>> BTW, I still have 2 questions.
>>
>> 1. In final build, why need
>>
>>GCC_PLUGINS_CFLAGS="${GCC_PLUGINS_CFLAGS}"
>>
>> D
Commit-ID: a06cc94f3f8dfab74fe7fac3a6e9f15d77566d00
Gitweb: https://git.kernel.org/tip/a06cc94f3f8dfab74fe7fac3a6e9f15d77566d00
Author: Cao jin <caoj.f...@cn.fujitsu.com>
AuthorDate: Thu, 8 Feb 2018 14:38:57 +0800
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 13
Commit-ID: a06cc94f3f8dfab74fe7fac3a6e9f15d77566d00
Gitweb: https://git.kernel.org/tip/a06cc94f3f8dfab74fe7fac3a6e9f15d77566d00
Author: Cao jin
AuthorDate: Thu, 8 Feb 2018 14:38:57 +0800
Committer: Ingo Molnar
CommitDate: Tue, 13 Feb 2018 13:08:46 +0100
x86/build: Drop superfluous
On 02/12/2018 10:48 PM, Masahiro Yamada wrote:
> 2018-02-12 13:22 GMT+09:00 Cao jin <caoj.f...@cn.fujitsu.com>:
>> Hi Masahiro-san,
>>
>> As I remember, init/ is already built during recursive make, and I did
>> a clean build(make mrproper, make localmodcon
On 02/12/2018 10:48 PM, Masahiro Yamada wrote:
> 2018-02-12 13:22 GMT+09:00 Cao jin :
>> Hi Masahiro-san,
>>
>> As I remember, init/ is already built during recursive make, and I did
>> a clean build(make mrproper, make localmodconfig) with all plugins
>>
{srctree}/scripts/Makefile.build" obj=init
GCC_PLUGINS_CFLAGS="${GCC_PLUGINS_CFLAGS}"
-
archive_builtin
#link vmlinux.o
--
Sincerely,
Cao jin
{srctree}/scripts/Makefile.build" obj=init
GCC_PLUGINS_CFLAGS="${GCC_PLUGINS_CFLAGS}"
-
archive_builtin
#link vmlinux.o
--
Sincerely,
Cao jin
ALIGN(8) is superfluous since macro TEXT_TEXT already has one.
bonus: indentation fix, spaces -> tab.
Signed-off-by: Cao jin <caoj.f...@cn.fujitsu.com>
---
arch/x86/kernel/vmlinux.lds.S | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/vmlinu
1 - 100 of 367 matches
Mail list logo
