Yes, it’s either immediately apparent and fixed in 20 minutes (in which case it is not a good candidate for a GSoC project) or “we have no idea, no one understands it”, in which case it is also not a good GSoC project.
We need things that have a well-defined roadmap for GSoC and this isn’t one.
Software for analysis and video:
Software written in cross-platform python:
https://vusb-analyzer.sourceforge.net/download.html
Debugging Usually Slightly Broken (USB) Devices and Drivers:
Documentation for reference:
Some ideas from me:
I wonder how virtual memory should be handled in this case.
We can compile everything as a static binary (so no shared Linux dynamic object would occupy the address space).
Then, the Haiku kernel can just map anything it wants using mmap and MAP_FIXED.
There is already a patch implementing this on the bugtracker, it was fully working, for reasons I don’t understand it was never merged.
I hope you don’t mean Haiku userland applications with everything, we compile every application as a shared library and parts of the system rely on this functionality 
No, it means only Haiku kernel build for Linux and userland process launch stub need to be statically linked. Haiku userland application binaries should run unmodified.
Maybe we should merge it then? My guess it was complicated to setup builds?
Before that, waddlesplash (or was it axeld?) suggested to redo it in a slightly different way. I didn’t look at it close enough to see if the change was really useful, but it would need basically rewriting the whole change with a different approach.
There were not much changes to the buildsystem, from that point of view you just configure your build as an hybrid with 64 bit primary arch and 32 bit secondary. The “magic” happens in syscall handlers.
If I remember correctly, in korli’s implementation, each syscall will determine if the caller app is 32bit, and convert pointers to 64bit.
Waddlesplash wanted to introduce stparate syscalls for the 32 and 64 bit versions whenever pointers are involved, and convert the syscall numbers. I’m not sure what the supposed benefits would be.
While comparing these approaches, we may also want to think about what a qemu-user inspired system would look like, for example to run x86 binaries on ARM systems. We should probably pick the one tqat makes that easier in the future?
A follow up to this would be allowing two secondary archs, x86 and x86_gcc2. They were both tested separately, or maybe at the same time by manually setting up a bootable partition with all needed packages. It would also require x86_gcc2 packages as secondary arch, which we currently don’t provide.
#ully integrating this may require re-thinking the concept of “secondary” arch and make all architectures be “primary”, that would mean the packages are the same when using x86_gcc2 as a secondary arch over x86_64, or as a primary arch on a 32bit system. Currently this would require packages with different internal organization (library paths, etc).
I also experimented with userland based approach (UserlandVM). The idea is to implement syscall translation fully on userland side and use special kernel interfaces only for mode switching. Currently it works for x86_64 host and riscv64 guest running with userland virtual machine and software emulation powered by TinyEMU or RVVM engine. x86_64 host and x86 guest need more work on syscall translation and hardware mode swithing.
How about a kernel driver that handles binaries not recognized by the normal runtime_loader and associates these binaries with a different syscall table? When a syscall is called control should be passed to this driver instead and syscall translation should happen there.
This way we can optionally install and uninstall x86 support or even ARM64 emulation support without using a different Haiku kernel version.
Why need a kernel driver? It is usually better to keep as much as possible in userspace for better stability and simplicity of development and testing. Kernel module seems have no speed benefits here. 32 bit x86 use commpage function call for syscalls, so it can be easily replaced with a call to syscall translation dispatcher.
We do need a kernel driver for virtualization though, if you are looking for kernel side work.
I like kernel side work, but I don’t know how type-1 hypervisors (or hypervisors in general really) work so it might be hard to get started on porting virtualization implementations to Haiku.
Yes, it is not an easy task and I am not sure we have anyone who knows more.
https://gitweb.dragonflybsd.org/dragonfly.git/tree/HEAD:/sys/dev/virtual/nvmm
https://gitweb.dragonflybsd.org/dragonfly.git/tree/HEAD:/sys/dev/virtual
With the monster MilkV Pioneer Risc-V machine being announced [1], here’s a next gen idea:
If someone built a Haiku on Haiku hypervisor with riscv host support (risc-v virtualization support: Xen and the RISC-V Hypervisor Extension ), then the Haiku foundation could let certain trusted devs to have remote dev access to this machine via socksify for package testing and compiling, especially since Haiku is light on memory usage vs other OS. Or perhaps a native Risc-V hypervisor platform will emerge soon. Then we can leverage our synergies to create hyperconvergent buzzwords of scale
Another idea is just multiple users running on the physical hardware, but we know that that is coming in R2.
[1] Milk-V
Also here’s more risc-v news, a Raspberry Pi form factor from MilkV: Milk-V Surprises with a Second RISC-V SBC — Physically Compatible with the Raspberry Pi 3 Model B - Hackster.io
I made own brush engine for my graphics program - https://paintbrush-x1.com/ . I was thinking to port it to Haiku as new application as a drawing program for kids (different brushes) or integrate it into WonderBrush.
Are any of those two options suitable for GSOC ?