Hello,

I am Trung Nguyen, and I'm looking for a chance to participate in GSoC 2024
with the *Emulating missing linux syscalls* project.

I am new to NetBSD, so I would appreciate any feedback for my answers below.

*About your project*
- Goal of the project: Improve NetBSD's `compat_linux` to make at least one
Linux binary that currently does not run properly under NetBSD work.
- Deliverables of the project: Mostly code changes to `sys/compat/linux`
and occasional patches to other parts of the kernel depending on the nature
of the syscalls implemented/fixed.
- Overall plan:
    + Get a simple Linux environment running with a shell, such as an
Alpine chroot.
    + Improve related tracing tools like `strace`.
    + Run more complex binaries, especially application runtimes that
heavily interact with the system such as `dotnet`.
- Similar software I am aware of:
    + WSL1 on Windows NT 10.0
    + FreeBSD's "Linuxulator"
    + blink (https://github.com/jart/blink). Runs entirely on a POSIX
userland, making it portable but requires architecture emulation along with
Linux syscall emulation, therefore less efficient than kernel modules.
- The project is not a port of any software but improving existing NetBSD
code.

*About your project and NetBSD*
- Experience with NetBSD: I am new to NetBSD. I have installed the OS and
recompiled the kernel to enable `compat_linux`. I have tried an Alpine
Linux root (my favorite option for testing any Linux compatibility layers),
but the `busybox` binary responsible for the default shell does not work.
- I have read through the source in `sys/compat/linux`.
- The project should result in improvement to a kernel subsystem.
- Interfaces: From what I understand:
    + A `probe` function checks for Linux binaries by looking at
Linux-specific traits distinguishing it from other ELFs.
    + A struct called `emul` contains function pointers related to process
lifetime and syscall dispatching for the compatibility layer.
- Currently I am not too familiar with these interfaces and many other
parts of NetBSD. However, as I tackle problems I can quickly read the
relevant parts of the source.
- Knowledge about the Linux ABI is required.
- I am very familiar with important parts of the Linux syscall ABI, having
worked on other projects emulating it in the past.

*About you*
- I am Trung Nguyen, also known as trungnt2910. I am an enthusiast in OS
development and OS compatibility layers. My GitHub account is at
https://github.com/trungnt2910.
    + Many projects I have worked on involve layers written in C or C++
translating to and from the Linux ABI, including:
        * Contributor to Darling: macOS binaries on Linux.
        * Collaborator of blink: Linux binaries on a variety of POSIX
platforms.
        * Maintainer of hyclone: Haiku OS binaries on Linux.
    + I also have experience with kernel-land C/C++ development:
        * Haiku OS: Fix kernel bugs that prevented the dotnet port from
running properly (Successful GSoC 2023 project:
https://www.haiku-os.org/blog/trungnt2910/2023-08-20_gsoc_2023_dotnet_port_final_report#haikuhaiku
)
        * lxmonika: https://github.com/trungnt2910/lxmonika -  A Windows
driver framework enabling developers to write custom compatibility layers
on the OS apart from WSL.
- I am new to programming with NetBSD, though I am used to working in a
generic Unix-like environment.
- This mail is my first discussion of the project.
- My preferred contact is at m...@trungnt2910.com.

I look forward to your suggestions, and hope that this could eventually
turn into a successful proposal for GSoC 2024.

Kind regards,

Trung Nguyen

Reply via email to