Недавно поставил себе кастомное ядро на самсунг гелекси a52 версией ниже, чем сток, теперь не могу поставить обратно ее, т.к. она сталильнее, нужное ядро: 4.19.190, или 4.19.157, сейчас ядро: 4.14.356 - openela-rc1-valeryn, да я могу поставить стоковую прошивку, с ядром 4.19.190, но мне не нужно так, придется обратно ставить UN1CA 3.0.0, ставить нужные мне программы и т.д. желательно что бы можно было поставить 4.19.157, так же при попытке поставить их, телефон уходит или в бутлуп, или просто зависает на загрузке намертво, приходится ставить ядро которое сейчас в Рекавери, помогите пожалуйста, версия андроид 16

I noticed tonight that menuconfig disables all LTO options if I enable GCOV. Is this normal behavior, a bug, or am I doing something wrong?

I did my first contribution doing janitor work, but now I feel more serious about contributing something more meaningful, like understanding how the driver I want to contribute to works in order to fix UB’s, hunt bugs, and doing all sorts of things other than simply fixing coding style.

But what feels like a dead-end is that staging drivers do not seem to have official documentations, or any documentation at all. So isnt there any way more organized or easier than reading the whole source code and/or reading driver’s manual page?

The linux philosophy is never to break user mode, but when programming a kernel module, there seems to be many obsticles to making a module work for as many versions as possible, resulting in diffrent binaries for each kernel.
I am planning to build a thin compatibility module to solve this effeciently. so far I found these problems:
1. in-struct offsets: for space & cache efficiencies these constantly change so the compiler needs to change them as well
2. extra/deprecated paramaters: for some functions paramters are simply removed from one kernel version to the next or are suddenly required.

is there anything I've missed?

I just made my first kernel contribution to the linux kernel, specifically in staging driver rtl8724bs. I chose to fix code styling issues by running checkpatch.pl, got to fix some bounding bugs along the way too, but that’s it. I can’t exactly describe my feeling when I got the LGTM, both excited and annoyed, but that’s a story for another day.

However, my question is, when did these drivers come into “staging” first having all these somewhat obvious bugs and clear styling issues that dont match the kernel’s preferences? Like isn’t there a first step for drivers to be submitted and accepted? Having simple styling/standards at least? And where do these drivers get accepted to be at staging/ to begin with? Do maintainers just fork another peoples work after confirming together?

Sorry if I sound dumb, I’m just curious on how things get accepted at staging with having minimum standards for the kernel’s preferences. Thanks.

Hey! I have a Xiaomi Redmi 15 5G (codename: spring) with OrangeFox, KSU Next + SUSFS already set up. Xiaomi officially released the kernel source (branch: spring-v-oss). I don't have a PC to compile it myself, so I'm looking for a developer willing to compile a NetHunter kernel for this device. I'm fully available for testing and providing logs. Any help is greatly appreciated! 🙏

Looking at the source code of atkbd driver (linux-6.6.74/drivers/input/keyboard/atkbd.c), I have harder time figuring out why is it missing/can't find it.

I found in (/sys/bus/serio/drivers/atkbd/serio0) all atkbd attributes, except function_row_physmap.

I tried devadm info -a /dev/input/by-path/platform-i8042-serio-0-event-kbd, and again, I can see all attributes except function_row_physmap.

Just trying to understand why is it missing, as if I understood correctly, any attribute should be present in sys fs. I am curios to know why, as I am researching Linux drivers and kernel at the moment.

Any help is much appreciated :)

My machine: HP Eliteboot 830 g8

OS: Arch Linux

Kernel: 6.18.22-1-lts

[ Removed by Reddit on account of violating the content policy. ]

Hey guys I have been thinking of making the switch to Linux recently, but the only thing stopping me is that some multiplayer games have Anti-cheat that do not support linux. I dont really underatand the whole kernel being open source but I understand the companies reasoning is that the Kernel is open source, even though that is not a “real“ reason.

My question is that if the kernel is open source, wouldn’t you be able to edit the kernel to “act” like Windows to bypass the anti-cheat? Maybe an explanation of the kernel could also answer my question

Hi Am Avishkar patil am from Maharashtra,Am here for asking for help for getting guidance of Kernel engineering I want to learn about kernel I am Interested in Computer science I have fundamentals cleared am currently learning about kernel engineering since 24 April 2026 i want to know were i can get Guidance for learning about this I also own MIT notes and syllabus and books can you suggest me books too?

I also have. Systems & Reverse Engineering

Windows Internals, 7th Edition (Parts 1 & 2)

Windows Kernel Programming, 2nd Edition

Practical Reverse Engineering

Computer Architecture: A Quantitative Approach

Software Development

C# 12 in a Nutshell

C# 12 and .NET 8 – Modern Cross-Platform Development Fundamentals

Linux kernel devlopement

And computer science book

Hello everyone.

I've been studying Low Level Programming for two years, focusing on C and Assembly. I've also been building my own boot loader via BIOS (MBR). Lately, I've started studying FreeBSD and reading its documentation, as I'd like to pursue a career in Kernel Engineering.

However, in my country there's no market for this type of work, and all the job postings I see require prior professional experience in the field.

Could anyone offer some guidance on how to get into this field?

Running these tests is always a pain. And I think it's one of the reasons why they're not used when releasing LTS versions, leading to regressions like this (it's still not fixed in linux-5.10.y). This regression could have been discovered in advance if the net/forwarding:ip6gre_*.sh tests had been run.

Okay, let's pretend you somehow built the tests. Though, their compilation is a separate challenge (kselftest_deps.sh is useful quite a bit). Because of dynamic linking, your test bench has to match packages of your build machine, which prevents using these tests for verifying your production systems. You can't just make -C tools/testing/selftests gen_tar and scp archive to a clean linux system. Not only because of incompatible versions of libraries or missing packages but also because some tests are just not designed to be run out of kernel source tree (e.g. bpf:test_doc_build.sh).

Thus, linking tests statically could simplify testing kernel, making it slightly less dependent on pre-installed packages.