Proposal (don’t know timings):
Haiku API in python3
1 Like
1 Like
USB Audio Class with HAL Driver for STM32F103RC:
USB Audio Class tools box:
1 Like
Those are to implement usb audio devices with microcontrollers. We need to finish the implementation of the part that runs in the computer and sends audio to the devices.
Also we haae a driver that’s 99% complete and Waddlesplash spent some time looking at it and couldn’t find what the remaining proolem was. Sounds like the worst thing you coulo ask a GsoC contributor to work on.
1 Like
Link to USB Audio Class tools box, is for computers, has hardware code references!
https://git.haiku-os.org/haiku/log/src/add-ons/kernel/drivers/audio/usb
https://git.haiku-os.org/haiku/log/src/add-ons/kernel/drivers/audio/usb_audio
2 Likes
To be fair, I’m not really an expert at Haiku’s audio systems. It could be that, to someone who does know their way around our userland/audio drivers interfaces, the problem would be immediately apparent…
6 Likes
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.
5 Likes
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:
2 Likes
Some ideas from me:
- HoH64: Haiku on Haiku 64. Run x86, and more importantly, x86_gcc2 on Haiku x86_64.
- User-mode Haiku: Run the whole Haiku kernel as a Linux process. Syscalls from unmodified Haiku binaries can be intercepted using ptrace.
1 Like
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.
4 Likes
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?
1 Like
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).
3 Likes