Ting 이네 Software 이야기

The title says it all (surprisingly).

This is my test.

Test source code - a.c

#include <stdio.h>


int main() {
    int a = 0;
    printf("%d\n", 1 / a);
    printf("Done\n");
    return 0;
}

Build it for x64 (ubuntu 22.04).

$ lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:    22.04
Codename:    jammy

$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

$ gcc a.c
$ ./a.out
Floating point exception (core dumped)

However, built it for aarch64 with android-ndk toolchain.

$ android/ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android33-clang a.c
$ adb push a.out /data/a.out
$ adb shell /data/a.out
0
Done

No error! Just gives ZERO!!

You can get depth image at OpenGL or Vulkan. This article assumes VK_FORMAT_D32_SFLOAT of Vulkan is used as format of depth buffer..
In this case, pixel value of depth image is z-value at NDC space. So, you can reconstruct it's position in world space by using inverse of transformation matrix including perspective matrix.
Then, how can you get this depth image at Blender?
First of all, to get depth value at Blender, you have to make Output-File-Node of OpenEXR image format, and connect it to Depth (or Z) attribute.
But, value stored in this image is not depth(Z) value in NDC space. It's depth value at your view space. So, it's good practice clamping value between near-Z and far-Z.
That is value is between near-Z and far-Z. To get real z-value in NDC space, you can use your projection matrix(usually perspective matrix).
You don't need to know (x, y) value corresponding to this depth value - you can easily capture this by having a look perspective matrix multiplication.
In summary, you have to follow below steps.
- Getting OpenEXR depth image of view space at Blender.
- Convert it by using projection matrix to get depth value at NDC space.

    : You can use even Python: cv2, struct.(un)pack, torchvision, PIL and so on.

- Use (u,v) value and depth value of image to reconstruct position in view space.

This is not a topic of Linux kernel. I would like to introduce one of popular way protecting Policy file for SELinux that used in lots of linux(including embedded linux) system.

systemd is widely user process that is widely used as init process at Linux in these days. systemd loads SELinux data from SELinux root directoy (/etc/selinux by default) if SELinux is enabled, at very early stage. And then services registered are started.

Here is sample mount status.

...(skip)...
overlay on /etc type overlay (rw,relatime,rootcontext=system_u:object_r:etc_t:s0,seclabel,lowerdir=/etc,upperdir=/overlay/etc,workdir=/overlay/.etc-work,x-systemd.automount)
...(skip)...

And you can easily find systemd service doing this mount task.

According to steps of systemd, policy of SELinux is loaded before /etc/ is hidden behind by overlay filesystem. So, original SELinux data can be safely protected from users.

This way is very popular way protecting original data from users. You can apply this trick to various cases for your system.