Posts

End of the Mentorship start of new journey

 The short Mentorship reaches its end , it used to be 6 months long but in this case it was a compressed 3 months one. The experience started with an initial filter based in a very good training available freely in the Linux Foundation site,  I think it worth mention because that Beginners' Guide to Linux Kernel  has everything you need to do your first commit. Even there are others resources in Linux Foundation that are not free, I think this is the only one you need to start.  Then started the real mentorship and the hurry to get your target of at least 5 accepted patches and that's a bit stressful:   first you start with  syzkaller   a great tool leverage from Google to run fuzzy testing. It's a really astonishing thing because give you the kernel and the C code to reproduce the issue ... or it should because not always you get the `reproducer` (how it's called that C code to reproduce the issue) . Check this blog entry for a really good guide on h...

Cross compiling , yes but with `gcc` or `clang` ?

 I need to build a driver for a graphic card of the powerpc architecture.  Build with `gcc` The steps to do that seems more of less easy: add toolchain, run make with options to point new toolchain. First:  Here in opensuse with `zypper` we added  the `ppc64le` toolchain. sudo zypper in cross-ppc64le-linux-glibc-devel cross-ppc64le-gcc15-bootstrap   Second: Clean previous configs with `mrproper` and then run `all` (maybe you need to run also `menuconfig`) make -j$(nproc) O=~/LF/cross/powerpc ARCH=powerpc HOSTCC=gcc CROSS_COMPILE=powerpc64le-suse-linux- mrproper make ARCH=powerpc mrproper make -j$(nproc) V=1 O=~/LF/cross/powerpc ARCH=powerpc HOSTCC=gcc CROSS_COMPILE=powerpc64le-suse-linux- all   Log: This is a line from the output, we see how the compiler name is composed with $CROSS_COMPILE plus the compiler name `gcc` in this case. powerpc64le-suse-linux-gcc -Wp,-MMD,lib/.iomem_copy.o.d -nostdinc -I/home/jg/LF/linux_work/linux_mainline/arch/...

I need a i386 kernel.

 Long time ago everything changed to 64bits for the most common architectures like x86 and arm.  We just don't remember i386 but sometimes we need to build an old 32bits .   What I need to build an i386 (how I did it) The toolchain for the i386 Tell the kernel build system that we want an architecture different from default (which now is 64bits)   That's it , in fact the linux kernel build systems is used to build several different architectures so this exercise is nothing for this beast.   I'll add the commands for my OpenSuse , for other distros it should be very similar sudo zypper in cross-i386-binutils   export ARCH=i386 ;time make LLVM=1 -j$(nproc) all CC='ccache clang'   You can check that the binary is one of 32bits architecture with the file command   $file arch/x86/boot/bzImage arch/x86/boot/bzImage: Linux kernel x86 boot executable, bzImage, version 6.16.0-rc1-dirty (jg@dell) #28 SMP PREEMPT_DYNAMIC Sat Oct ...

My kernel is building ... after 1h `make` exits with no error

Image
 arghhhhh ... after so much time building all the sources the vmlinux is not created.   I did repeat the process after a make clean and an extra hour ... but again no vmlinux     The kernel build process has several steps like creating .o from .c and .h files but then objtool will do an static analysis of the generated object.   The problem comes at the end when the biggest vmlinux object must be analyzed with objtool and if options like  CONFIG_DEBUG_INFO the number DWARF data increases and eveything blows.   How much memory you'll need ... in my case with a 16GB laptop needed to add swap to allow generate finally the vmlinux  .   In the image you can see objtool with 79.93% of the memory , so aprox 12GB of ram     

Alarm!, repro is not working, I'm blocked

 One of the initial tasks when you start working in the Linux Kernel as a newbie is fixing errors. To fix errors the way to go is pick an error from the  syzkaller   I'll try to add here some tricks to help you work with less headaches based in my own headaches :   The basic step to reproduce the error is run the  repro  C program that it's provided in the page of the selected error. The problem I had is after some successful tries to reproduce the error suddenly it didn't work anymore. I was able to run the program but it ends and with no error. What I've found is that the sandbox folder for the  repro  already exists and that caused the problem. The solution was as easy as to delete the  syz-tmp folder in the image you're using to run your kernel and reproduce the error. These two command in the host I use to run inside the qemu : scp -i ~/LF/syz/syzkaller/trixie.id_rsa -P 10021 -o UserKnownHostsFile=/dev/null -o ...

Long time since I compiled my first kernel ...

  Long time since I compiled my first kernel, I think it was a box with an Intel 386sx . Always with an eye on that area then this summer of 2025 in an entry an entry in LinkedIn I saw a comment about the Linux Foundation mentoring program so I joined to the kernel mentoring program. Now I’ve been accepted and I’m starting the journey… let’s see what I can learn and most important what I can contribute to this wonderful software that I’ve been using for decades now.