Skip to content

Easing the setup of compiler_builtins #69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ojeda opened this issue Jan 12, 2021 · 0 comments · Fixed by #80
Closed

Easing the setup of compiler_builtins #69

ojeda opened this issue Jan 12, 2021 · 0 comments · Fixed by #80
Labels
• misc Related to other topics (e.g. CI).

Comments

@ojeda
Copy link
Member

ojeda commented Jan 12, 2021 •
edited
Loading

What would it take to make compiler_builtins be something that didn't need to manually be installed? There are a few approaches:

  • For rustup to include it as a component, so that installation is easier (and it is automatically updated etc.).
  • That the rust repo includes it (moonshot, but for those that need rust-src it is much more likely that they need it too).
  • Removing it as a dependency by copying the needed builtins into the tree (the kernel does this for others, too).
  • Removing it as a dependency by not using alloc (e.g. if for other reasons we end up with our own alloc).
@ojeda ojeda added - optional • misc Related to other topics (e.g. CI). labels Jan 12, 2021
@ojeda ojeda mentioned this issue Jan 12, 2021
Merged
@adamrk adamrk mentioned this issue Jan 20, 2021
Closed
ojeda added a commit that referenced this issue Jan 21, 2021
@ojeda
Integrate compiler_builtins
cefa66f 
This simplifies onboarding, it is smaller, faster to compile and
it is one less dependency to worry about.

It also simplifies the build system a tiny bit since now everything
uses the 2018 edition.

Fixes #69.

Signed-off-by: Miguel Ojeda <[email protected]>
@ojeda ojeda mentioned this issue Jan 21, 2021
Merged
ojeda added a commit that referenced this issue Jan 21, 2021
@ojeda
Integrate compiler_builtins
28abd4e 
This simplifies onboarding, it is smaller, faster to compile and
it is one less dependency to worry about.

It also simplifies the build system a tiny bit since now everything
uses the 2018 edition.

Fixes #69.

Signed-off-by: Miguel Ojeda <[email protected]>
ojeda added a commit that referenced this issue Jan 21, 2021
@ojeda
Integrate compiler_builtins
d074991 
This simplifies onboarding, it is smaller, faster to compile and
it is one less dependency to worry about.

It also simplifies the build system a tiny bit since now everything
uses the 2018 edition.

Fixes #69.

Signed-off-by: Miguel Ojeda <[email protected]>
@ojeda ojeda closed this as completed in #80 Jan 23, 2021
matthewtgilbride pushed a commit to matthewtgilbride/linux that referenced this issue Mar 7, 2023
@liu-song-6
md: fix incorrect declaration about claim_rdev in md_import_device
b0907ca 
Commit fb541ca ("md: remove lock_bdev / unlock_bdev") removes
wrappers for blkdev_get/blkdev_put. However, the uninitialized local
static variable of pointer type 'claim_rdev' in md_import_device()
is NULL, which leads to the following warning call trace:

  WARNING: CPU: 22 PID: 1037 at block/bdev.c:577 bd_prepare_to_claim+0x131/0x150
  CPU: 22 PID: 1037 Comm: mdadm Not tainted 6.2.0-rc3+ Rust-for-Linux#69
  ..
  RIP: 0010:bd_prepare_to_claim+0x131/0x150
  ..
  Call Trace:
   <TASK>
   ? _raw_spin_unlock+0x15/0x30
   ? iput+0x6a/0x220
   blkdev_get_by_dev.part.0+0x4b/0x300
   md_import_device+0x126/0x1d0
   new_dev_store+0x184/0x240
   md_attr_store+0x80/0xf0
   kernfs_fop_write_iter+0x128/0x1c0
   vfs_write+0x2be/0x3c0
   ksys_write+0x5f/0xe0
   do_syscall_64+0x38/0x90
   entry_SYSCALL_64_after_hwframe+0x72/0xdc

It turns out the md device cannot be used:

  md: could not open device unknown-block(259,0).
  md: md127 stopped.

Fix the issue by declaring the local static variable of struct type
and passing the pointer of the variable to blkdev_get_by_dev().

Fixes: fb541ca ("md: remove lock_bdev / unlock_bdev")
Cc: Christoph Hellwig <[email protected]>
Signed-off-by: Adrian Huang <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Song Liu <[email protected]>
ojeda pushed a commit that referenced this issue Apr 8, 2025
@masahir0y
kbuild: deb-pkg: don't set KBUILD_BUILD_VERSION unconditionally
6260406 
In ThinPro, we use the convention <upstream_ver>+hp<patchlevel> for
the kernel package. This does not have a dash in the name or version.
This is built by editing ".version" before a build, and setting
EXTRAVERSION="+hp" and KDEB_PKGVERSION make variables:

    echo 68 > .version
    make -j<n> EXTRAVERSION="+hp" bindeb-pkg KDEB_PKGVERSION=6.12.2+hp69

    .deb name: linux-image-6.12.2+hp_6.12.2+hp69_amd64.deb

Since commit 7d4f07d ("kbuild: deb-pkg: squash
scripts/package/deb-build-option to debian/rules"), this no longer
works. The deb build logic changed, even though, the commit message
implies that the logic should be unmodified.

Before, KBUILD_BUILD_VERSION was not set if the KDEB_PKGVERSION did
not contain a dash. After the change KBUILD_BUILD_VERSION is always
set to KDEB_PKGVERSION. Since this determines UTS_VERSION, the uname
output to look off:

    (now)      uname -a: version 6.12.2+hp ... #6.12.2+hp69
    (expected) uname -a: version 6.12.2+hp ... #69

Update the debian/rules logic to restore the original behavior.

Fixes: 7d4f07d ("kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules")
Signed-off-by: Alexandru Gagniuc <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
• misc Related to other topics (e.g. CI).
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Integrate compiler_builtins Rust-for-Linux/linux
1 participant
@ojeda