How to deploy changes in tegracam-ctrls.c to other rootfs

Hello,
for my sensor driver, I had to modify

tegram_ctrls.c
sensor_common.c
media/camera_common.h
tegra-v4l2-camera.h

What would be the best way to give those changed compiled binaries to someone so he can extract it to his rootfs?
I am new to Linux development, but as I understood, those are not modules, so there are no .ko files I can just copy. So I thought they are built into the kernel, but just changing the “Image” file still got me some errors.

Am I missing something or do you have any idea how I can achieve this without copying whole rootfs or is this the only option?

I have another question. My sensor driver is .ko file and it is configured with ‘m’ in the defconfig.
Still it gets loaded automatically on bootup. I would like to load it with modprobe, but not automatically. How can I achieve this?

Thank you so much for your help!
Keep up the good work!

Best regards,
jb

What software were you building after the modification?

A lot of software is “user space”, and just an executable program. Other software is “kernel space”, meaning a kernel modification, either directly or via a kernel module (a kernel module is part of the kernel like any other code, but it can be loaded or unloaded at run time).

Often specialty software will need a certain kernel feature, which could be from a “.ko” kernel module, or it could be from a new “/boot/Image” (be careful working on the Image, it could leave the system unbootable if done wrong), but a user space program might be required to use that kernel feature. Just as a contrived example, imagine you have support for hardware accelerated encryption…the kernel would support this, but it would be up to an end program to try to use the feature.

Regarding where modules go, the Image searches for modules somewhere within:
/lib/modules/$(uname -r)/kernel
(copy and paste that as an argument to “cd”, then run it and use “ls” to see what is there)

The actual output of “uname -r” is a combination of the base kernel version, plus the setting of “CONFIG_LOCALVERSION” at the time of compile.

Notice that in the actual kernel source where a “.ko” (module) is generated, there will be a path. Just as a contrived example, imagine your kernel source has subdirectory “drivers/net/usb/”, and that you’ve just built a driver for a USB r8152 device. The module would be found (after built) at “drivers/net/usb/r8152.ko”. Your final file copy would go to:
/lib/modules/$(uname -r)/kernel/drivers/net/usb/r8152.ko

After putting it there you could run “sudo depmod -a”, and then any attempt to use that driver feature should find it and use it. You could also reboot.

I don’t know anything about any end user software or kernel feature for your specific case, the above is all just “in general”.

Note that if you are using some hardware using a specialized interface, then you might also need to adjust your device tree. Hot plug systems such as USB are able to self-describe so the driver can find it, but other specialized interfaces might need the device tree to tell the driver what address to point to. Basically, that device tree content could be passed to the driver you just added via the “.ko” file (if and only if there is no automated method for the driver to find the hardware).