Skip to content

C
clone-Linux

gsplhtlxg / clone-Linux

通知 2
Star 0
Fork 1
C
clone-Linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 06 11月, 2018 1 次提交
    • M
      kbuild: rpm-pkg: fix binrpm-pkg breakage when O= is used · 21b42eb4
      由 Masahiro Yamada 提交于 
      Zhenzhong Duan reported that running 'make O=/build/kernel binrpm-pkg'
failed with the following errors:

  Running 'make O=/build/kernel binrpm-pkg' failed with below two errors.

  Makefile:600: include/config/auto.conf: No such file or directory

  + cp make -C /mnt/root/kernel O=/build/kernel image_name make -f
  /mnt/root/kernel/Makefile ...
  cp: invalid option -- 'C'
  Try 'cp --help' for more information.

Prior to commit 80463f1b ("kbuild: add --include-dir flag only
for out-of-tree build"), both srctree and objtree were added to
--include-dir redundantly, and the wrong code 'make image_name'
was working by relying on that. Now, the potential issue that had
previously been hidden just showed up.

'make image_name' recurses to the generated $(objtree)/Makefile and
ends up with running in srctree, which is incorrect. It should be
invoked with '-f $srctree/Makefile' (or KBUILD_SRC=) to be executed
in objtree.

Fixes: 80463f1b ("kbuild: add --include-dir flag only for out-of-tree build")
Reported-by: NZhenzhong Duan <zhenzhong.duan@oracle.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      21b42eb4
  3. 28 7月, 2018 12 次提交
  5. 19 7月, 2018 2 次提交
  7. 17 5月, 2018 1 次提交
    • R
      kbuild: deb-pkg improve maintainer address generation · d5940c60
      由 Riku Voipio 提交于 
      There is multiple issues with the genaration of maintainer string

It uses DEBEMAIL and EMAIL enviroment variables, which may contain angle brackets,
creating invalid maintainer strings. The documented KBUILD_BUILD_USER and
KBUILD_BUILD_HOST variables are not used. Undocumented and uncommon NAME
variable is used. Refactor the Maintainer string to:

- use EMAIL or DEBEMAIL directly if they are in form "name <user@host>"
- use KBUILD_BUILD_USER and KBUILD_BUILD_HOST if set before falling
  back to autodetection
- no longer use NAME variable or the useless Anonymous string

The logic is switched from multiline if/then/fi statements to compact
shell variable substition commands.
Reported-by: NMathieu Malaterre <malat@debian.org>
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      d5940c60
  9. 13 4月, 2018 1 次提交
  11. 07 4月, 2018 1 次提交
  13. 28 3月, 2018 2 次提交
  15. 12 12月, 2017 2 次提交
    • M
      kbuild: pkg: make out-of-tree rpm/deb-pkg build immediately fail · 262dad68
      由 Masahiro Yamada 提交于 
      We do not support out-of-tree building of rpm-pkg / deb-pkg.  If O=
is given, the build should be terminated, but the "false" command is
not effective since it is not the last command in the cmd_src_tar.
Then, rpm-pkg / deb-pkg tries to continue building, and fails for a
different reason.

Set -e option so that the "false" terminates the building immediately.

I also put the error messages to stderr, and made it stand out more.

For example, "make O=foo rpm-pkg" will fail as follows:

  /bin/bash ../scripts/package/mkspec >./kernel.spec
    TAR     kernel-4.15.0_rc2+.tar.gz

    ERROR:
    Building source tarball is not possible outside the
    kernel source tree. Don't set KBUILD_OUTPUT, or use the
    binrpm-pkg or bindeb-pkg target instead.

  ../scripts/package/Makefile:53: recipe for target 'rpm-pkg' failed
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: NJim Davis <jim.epost@gmail.com>
      262dad68
    • P
      scripts/package: snap-pkg target · 5704d455
      由 Paolo Pisati 提交于 
      Following in footsteps of other targets like 'deb-pkg, 'rpm-pkg' and 'tar-pkg',
this patch adds a 'snap-pkg' target for the creation of a Linux kernel snap
package using the kbuild infrastructure.

A snap, in its general form, is a self contained, sandboxed, universal package
and it is intended to work across multiple distributions and/or devices. A snap
package is distributed as a single compressed squashfs filesystem.

A kernel snap is a snap package carrying the Linux kernel, kernel modules,
accessory files (DTBs, System.map, etc) and a manifesto file.  The purpose of a
kernel snap is to carry the Linux kernel during the creation of a system image,
eg. Ubuntu Core, and its subsequent upgrades.

For more information on snap packages: https://snapcraft.io/docs/Signed-off-by: NPaolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      5704d455
  17. 23 11月, 2017 2 次提交
    • M
      kbuild: rpm: prompt to use "rpm-pkg" if "rpm" target is used · ebaad7d3
      由 Masahiro Yamada 提交于 
      The "rpm" has been kept for backward compatibility since pre-git era.
I am planning to remove it after the Linux 4.18 release.  Annouce the
end of the support, prompting to use "rpm-pkg" instead.

If you use "rpm", it will work like "rpm-pkg", but warning messages
will be displayed as follows:

  WARNING: "rpm" target will be removed after Linux 4.18
           Please use "rpm-pkg" instead.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      ebaad7d3
    • M
      kbuild: pkg: use --transform option to prefix paths in tar · 2dbc644a
      由 Masahiro Yamada 提交于 
      For rpm-pkg and deb-pkg, a source tar file is created.  All paths in
the archive must be prefixed with the base name of the tar so that
everything is contained in the directory when you extract it.

Currently, scripts/package/Makefile uses a symlink for that, and
removes it after the tar is created.

If you terminate the build during the tar creation, the symlink is
left over.  Then, at the next package build, you will see a warning
like follows:

  ln: '.' and 'kernel-4.14.0+/.' are the same file

It is possible to fix it by adding -n (--no-dereference) option to
the "ln" command, but a cleaner way is to use --transform option
of "tar" command.  This option is GNU extension, but it should not
hurt to use it in the Linux build system.

The 'S' flag is needed to exclude symlinks from the path fixup.
Without it, symlinks in the kernel are broken.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      2dbc644a
  19. 14 11月, 2017 7 次提交
  21. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      由 Greg Kroah-Hartman 提交于 
      Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  23. 09 10月, 2017 3 次提交
    • M
      kbuild: rpm-pkg: clean up mkspec · 5289c322
      由 Masahiro Yamada 提交于 
      Clean up the mkspec without changing the behavior.

 - grep CONFIG_DRM=y more simply

 - move "EXCLUDE" out of the "%install" section because it can be
   computed when the spec file is generated

 - remove "BuildRoot:" field, which is now redundant

 - do not mkdir $RPM_BUILD_ROOT/lib/modules explicitly because it
   is automatically created by "make modules_install"

 - exclude "%package devel" from source package spec file because
   it does not make sense where "%files devel" is already excluded

 - exclude "%build" from source package spec file

 - remove unneeded "make clean" because we had already cleaned
   before making tar file

 - merge two %ifarch ia64 conditionals

 - replace KBUILD_IMAGE with direct use of $(make image_name)

 - remove trailing empty line from the spec file
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      5289c322
    • M
      kbuild: rpm-pkg: install vmlinux.bz2 unconditionally · 81771ce2
      由 Masahiro Yamada 提交于 
      This conditional was added by commit fc370ecf ("kbuild: add
vmlinux to kernel rpm").  Its git-log mentioned vmlinux.bz2 was
necessary for debugging, but did not explain why ppc64 was an
exception.  I see no problem to copy vmlinux.bz2 all the time.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      81771ce2
    • M
      kbuild: rpm-pkg: remove ppc64 specific image handling · 6736ce27
      由 Masahiro Yamada 提交于 
      This conditional was added by commit 1a0f3d42 ("kbuild: fix
make rpm for powerpc").  Its git-log explains the default kernel
image is zImage, but obviously the current arch/powerpc/Makefile
does not set KBUILD_IMAGE, so the image file is actually vmlinux.

Moreover, since commit 09549aa1 ("deb-pkg: Remove the KBUILD_IMAGE
workaround"), all architectures are supposed to set the full path to
the image in KBUILD_IMAGE.  I see no good reason to differentiate
ppc64 from others.  Rip off the conditional.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      6736ce27
  25. 20 9月, 2017 3 次提交
    • M
      kbuild: rpm-pkg: fix version number handling · 25b080bd
      由 Masahiro Yamada 提交于 
      The "Release:" field of the spec file is determined based on the
.version file.

However, the .version file is not copied to the source tar file.
So, when we build the kernel from the source package, the UTS_VERSION
always indicates #1.  This does not match with "rpm -q".

The kernel UTS_VERSION and "rpm -q" do not agree for binrpm-pkg, either.
Please note the kernel has already been built before the spec file is
created.  Currently, mkspec invokes mkversion.  This script returns an
incremented version.  So, the "Release:" field of the spec file is
greater than the version in the kernel by one.

For the source package build (where .version file is missing), we can
give KBUILD_BUILD_VERSION=%{release} to the build command.

For the binary package build, we can simply read out the .version file
because it contains the version number that was used for building the
kernel image.

We can remove scripts/mkversion because scripts/package/Makefile need
not touch the .version file.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      25b080bd
    • M
      kbuild: deb-pkg: remove firmware package support · cc18abbe
      由 Masahiro Yamada 提交于 
      Commit 5620a0d1 ("firmware: delete in-kernel firmware") deleted
in-kernel firmware support, including the firmware install command.

So, the firmware package does not make sense any more.  Remove it.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NRiku Voipio <riku.voipio@linaro.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc18abbe
    • M
      kbuild: rpm-pkg: delete firmware_install to fix build error · 9e090074
      由 Masahiro Yamada 提交于 
      Commit 5620a0d1 ("firmware: delete in-kernel firmware") deleted
in-kernel firmware support, including "make firmware_install".

Since then, "make rpm-pkg" / "make binrpm-pkg" fails to build with
the error:

  make[2]: *** No rule to make target `firmware_install'.  Stop.

Commit df85b2d7 ("firmware: Restore support for built-in firmware")
restored the build infrastructure for CONFIG_EXTRA_FIRMWARE, but this
is out of the scope of "make firmware_install".  So, the right thing to
do is to kill the use of "make firmware_install".

Fixes: 5620a0d1 ("firmware: delete in-kernel firmware")
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e090074
  27. 12 9月, 2017 2 次提交