home.social

Search

231 results for “kernellogger”

  1. Interesting detail in the description of the main EFI changes merged for 6.9[1]:

    "'"Avoid creating mappings that are both writable and executable while running in the EFI boot services. This is a prerequisite for getting the x86 loader signed by MicroSoft again, which allows the distros to install on x86 PCs that ship with EFI secure boot enabled."'"

    [1] git.kernel.org/torvalds/c/70ef

  2. Interesting detail in the description of the main EFI changes merged for #Linux 6.9[1]:

    "'"Avoid creating mappings that are both writable and executable while running in the EFI boot services. This is a prerequisite for getting the x86 #shim loader signed by MicroSoft again, which allows the distros to install on x86 PCs that ship with EFI secure boot enabled."'"

    [1] git.kernel.org/torvalds/c/70ef

    #Kernel #LinuxKernel #SecureBoot

  3. Interesting detail in the description of the main EFI changes merged for #Linux 6.9[1]:

    "'"Avoid creating mappings that are both writable and executable while running in the EFI boot services. This is a prerequisite for getting the x86 #shim loader signed by MicroSoft again, which allows the distros to install on x86 PCs that ship with EFI secure boot enabled."'"

    [1] git.kernel.org/torvalds/c/70ef

    #Kernel #LinuxKernel #SecureBoot

  4. Interesting detail in the description of the main EFI changes merged for #Linux 6.9[1]:

    "'"Avoid creating mappings that are both writable and executable while running in the EFI boot services. This is a prerequisite for getting the x86 #shim loader signed by MicroSoft again, which allows the distros to install on x86 PCs that ship with EFI secure boot enabled."'"

    [1] git.kernel.org/torvalds/c/70ef

    #Kernel #LinuxKernel #SecureBoot

  5. #Glibc 2.43 is out:

    inbox.sourceware.org/libc-alph

    A few highlights:

    * Experimental support for building with #clang has been added.

    * [a bunch of ISO C23 stuff]

    * Support for mseal and openat2 on #Linux

    * Additional optimized and correctly rounded mathematical functions have been imported from the CORE-MATH project […]

    * Unicode support has been updated to Unicode 17.0.0.

  6. ""Dumping packets from a network interface is a common debugging step. […] excessive and uncontrolled dumping can quickly become overwhelming, in terms of the amount of data and the impact on the inspected system. […] In this article, we will explore Retis[1] filtering capabilities, highlighting the differences, similarities, and expectations compared to other existing tools.""

    developers.redhat.com/articles

    [1] from github.com/retis-org/retis "Retis – #Tracing (filtered) packets in the #Linux #networking stack, using #eBPF probes and interfacing with control and data paths such as #OvS or #Netfilter."

    #Linux #Kernel #eBPF #networking #LinuxKernel #tracing

  7. "'[…] was created as a tool to unblock future releases — not intended as a global reinvention of all source code management; Linus’s comments highlight that he explicitly saw source code management as the domain of other tools that would then interface with git. […]'"

    graphite.dev/blog/bitkeeper-li

  8. Introduction to VirtIO, Part 2: Vhost

    blogs.oracle.com/linux/post/in

    Jonah Palmer writes: ""[…] #Vhost is a key optimization to #VirtIO that was created to offload data-plane processing from #Qemu into more efficient components.

    We’ll start off by taking a more in-depth look into the causes of overhead in the data plane of a pure VirtIO configuration. We’ll talk about the costly operations that are involved, such as VM exits, VM entries, context switches, and userspace processing by Qemu. Then we’ll introduce vhost and elaborate on how it addresses these issues by moving data-plane operations either into the kernel (kernel-based vhost) or into a specialized userspace process (via vhost-user).

    We’ll then dive into both #kernel-based vhost and vhost-user architectures, examining each in detail—including their advantages, drawbacks, typical use cases, and how they affect performance. […]"

    #Linux #LinuxKernel

  9. From the main #ntfs3 merge for #Linux 6.17[1]:

    "Added:
    - sanity check for file name
    - mark live inode as bad and avoid any operations

    Fixed:
    - handling of symlinks created in windows
    - creation of symlinks for relative path

    Changed:
    - cancel setting inode as bad after removing name fails
    - revert 'replace inode_trylock with inode_lock'"

    [1] git.kernel.org/torvalds/c/a11b

    #kernel #LinuxKernel

  10. From the main #ntfs3 merge for #Linux 6.17[1]:

    "Added:
    - sanity check for file name
    - mark live inode as bad and avoid any operations

    Fixed:
    - handling of symlinks created in windows
    - creation of symlinks for relative path

    Changed:
    - cancel setting inode as bad after removing name fails
    - revert 'replace inode_trylock with inode_lock'"

    [1] git.kernel.org/torvalds/c/a11b

    #kernel #LinuxKernel

  11. From the main merge for 6.17[1]:

    "Added:
    - sanity check for file name
    - mark live inode as bad and avoid any operations

    Fixed:
    - handling of symlinks created in windows
    - creation of symlinks for relative path

    Changed:
    - cancel setting inode as bad after removing name fails
    - revert 'replace inode_trylock with inode_lock'"

    [1] git.kernel.org/torvalds/c/a11b

  12. From the main #ntfs3 merge for #Linux 6.17[1]:

    "Added:
    - sanity check for file name
    - mark live inode as bad and avoid any operations

    Fixed:
    - handling of symlinks created in windows
    - creation of symlinks for relative path

    Changed:
    - cancel setting inode as bad after removing name fails
    - revert 'replace inode_trylock with inode_lock'"

    [1] git.kernel.org/torvalds/c/a11b

    #kernel #LinuxKernel

  13. From the main #ntfs3 merge for #Linux 6.17[1]:

    "Added:
    - sanity check for file name
    - mark live inode as bad and avoid any operations

    Fixed:
    - handling of symlinks created in windows
    - creation of symlinks for relative path

    Changed:
    - cancel setting inode as bad after removing name fails
    - revert 'replace inode_trylock with inode_lock'"

    [1] git.kernel.org/torvalds/c/a11b

    #kernel #LinuxKernel

  14. '"Many tools on have previously been limited by their reliance on stack unwinding algorithms that require commonly-used frame pointer optimizations to be disabled. This article introduces eu-stacktrace, a prototype tool that uses the toolkit’s unwinding libraries to support a sampling profiler to unwind frame pointer-less stack sample data."'

    developers.redhat.com/articles (from Serhei Makarov)

  15. The Input Stack on Linux – An End-To-End Architecture Overview

    venam.net/blog/unix/2025/11/27

    Patrick Louis writes: ""Let’s explore and deobfuscate the input stack on #Linux. Our aim is to understand its components and what each does. Input handling can be divided into two parts, separated by a common layer:

    #Kernel-level handling: It deals with what happens in the kernel and how events are exposed to user-space
    […]
    Exposed layer (middle)
    […]
    User-space handling:
    […]
    The Widgets, #XServer, #X11 window managers, and #Wayland compositors, which rely on everything else

    We’ll try to make sense of all this, one thing at a time, with a logical and coherent approach.""

    #LinuxKernel #evdev

  16. Really wondering what "upstream" actually refers to in "built-in #Debian #Linux environment with upstream support"

    * Qualcomm?

    * Debian? [Edit: stable or testing?]

    * Upstream #LinuxKernel, #Mesa, et. al.?

    Screenshot from docs.arduino.cc/hardware/uno-q/

    #arduino #unoq #kernel

  17. '"the Trusted Platform Module (TPM) […] allows an unattended auto-unlock, providing a pass is no longer required. That completely fits to secure disks that have been put in a machine in a safe location. With FDE [Full Disk Encryption] and TPM, your data becomes protected and cannot be read outside of your machine."'

    suse.com/c/full-disk-encryptio

  18. "An explanation of how #Linux handles system calls on x86-64 and why they show up as expensive operations in performance profiles

    blog.codingconfessions.com/p/w – from Abhinav Upadhyay

    #LinuxKernel #Kernel #syscalls

  19. GNU 2.44 is out:

    lists.gnu.org/archive/html/inf

    Some highlights:

    * Assembler:
    - Support for new architecture extensions for AArch64, Risc-V and x86.

    * Linker:

    - This now supports mixed LTO and non-LTO object files in relocatable output.
    - The ELF forms of the linker support a --image-base=<ADDR> option for compatibility with LLD.

    […] does not contain the sources for the gold linker […] now deprecated and will eventually be removed unless volunteers step forward […]

  20. Sebastian Aaltonen writes:

    ""[…]Modern graphics API have improved gradually in the past 10 years. […] As of today, there’s no single API that meets all our requirements, but if we combine their best bits together, we can build the perfect API for modern hardware.

    10 years ago, modern APIs were designed for CPU-driven binding models. New bindless features were presented as optional features and extensions. A clean break would improve the usability and reduce the API bloat and driver complexity significantly. It’s extremely difficult to get the whole industry behind a brand new API. I am hoping that vendors are willing to drop backwards compatibility in their new major API versions (Vulkan 2.0, DirectX 13) to embrace the fully bindless GPU architecture we have today. […]

    sebastianaaltonen.com/blog/no-

    #Linux #Graphics #Drivers #API #Vulkan #directx #opengl

  21. These two @lwn articles are prime examples of why good journalism matters and why you should pay money to make sure it thrives:

    They both look beyond the shiny statements from the different parties involved and outside commentators such as @torvalds in this case and explain just how it is from a mostly neutral[1] point of view so that you can make your own judgments.

    * GPLv2 and installation requirements – lwn.net/Articles/1052842/

    * SFC v. VIZIO: who can enforce the GPL? – lwn.net/Articles/1052734/

    [1] We are humans, and even if we try, we are never completely neutral – and a publication like #LWN that targets the FLOSS community obviously will somewhat look at things from the view of its target audience.

    #gpl #Linux #kernel #VIZIO #sfc

  22. + 7.0.0 is out: github.com/memtest86plus/memte

    "'"This release adds support for IMC (Integrated Memory Controller) polling to get live RAM settings on Intel Core 1st to 14th Gen and AMD Ryzen CPUs, and preliminary ECC polling support for selected AMD Ryzen CPUs.

    Complete changelog:

    IMC polling for live DRAM settings
    Preliminary support for ECC polling
    Add support for MMIO UART
    Add debugging options
    Bug fixes & optimizations"'"

  23. ""The name sure sounds like “mutex”, and that is where the name comes from: “fast, user space mutex”. But, it isn’t really, it’s a building block for concurrency primitives that ushered in a modern world of concurrent performance […]

    t was immediately clear that the futex was a huge improvement in highly concurrent environments. Just in that original paper, their tests with 1000 parallel tasks ran 20-120 times faster than sysv locks..🤯

    Needless to say, other common operating systems followed suit, including Windows in 2012 and macOS by 2016.

    These days, any good locking primitive is going to be based on a futex. […]""

    h4x0r.org/futex/

    #Linux #LinuxKernel #Kernel #Futex

  24. Have you heard the claim "Changing 30 lines of code in the could cut energy use at some data centers by up to 30 percent" that made the news two or three weeks ago?

    Did you wonder if it is really that simple as it sounds in many stories? Then you want to read the following article from @LWN. It describes things in a more nuanced and technical way, as yes, it is not that simple:

    lwn.net/Articles/1008399/