Another month has gone by and we’re entering now the last month of GSoC! So, what did I get done this month?
What works now that didn’t work before?
- The driver supports now the 16 IOCTL calls defined by the driver, which means that
both the frontend and the VMX backend are complete.
- EPT tables support: Much of my previous post content was about EPT tables and all the
problems I was having to get them working. Now support for them is complete and it works!
The EPT page fault handler only consists of one call to Haiku’s page fault handler, since it’s
everything integrated into Haiku’s virtual memory subsystem.
- libnvmm’s test suite is ported and all tests pass.
- QEMU (latest version from Haikuports) is capable, after applying a patch, of detecting NVMM support
and compile. It doesn’t work, sadly, something breaks after executing a few chunks of any given VM.
However, I didn’t make any progress on the SVM backend (which is still at a very early state). I’m beginning to realise that this is one thing I won’t be able to finish during the coding period.
I probably have all the pieces needed to port it but I have to look at the differences between SVM and VMX (there are a few) and that will probably take some time I might not have in the end.
Also, it’s worth to mention that despite getting more and more stuff working the list of TODO things keeps getting longer and longer.
Things on that list are improvements on performance and behavior (NVMM’s kidnaps the CPU which is probably not the best behavior if we want the system to be responsive, …). None of them is very long or difficult but there are a lot of those little things to do so they will end up requiring a considerable amount of time.
Nephele’s report:
This weekend in Berlin PulkoMandy and I attended an Coding sprint in Berlin to work on Renga, the XMPP client for Haiku.
On the first day we got settled first, had a nice introductory round and worked a bit on Renga. Everyone else seemed to want to work on end to end encryption, and then you have us: PulkoMandy improving the multi user chat experience, and me␚ deleting the settings menu. After all, quite a productive start!
WebKit wasn’t trying to draw anything to the screen. Turns out, it wasn’t aware that it was visible. No use drawing a web page when you’re invisible, right? Well, I told it that it is visible, and now it’s trying to draw to the screen. Of course, it crashes while trying to do so. It hasn’t tried to draw to the screen in ages. Everything is bit rotted!
So far, it looks like this will mostly be a collection of minor tasks. Nothing worthwhile to write about here yet, at least. If I’m lucky, it will stay that way and we can have a nice web page displayed by WebKit pretty soon.
This report covers hrev57754 through hrev57801.
intro
Hello, once again! It’s been three weeks since the last update, so here we go.
Good news, there is active development of the virtio sound driver for Haiku.
Key progress includes achieving playback on the device.
Getting the buffers ready.
We need to tell hmulti_audio where it should expect to write and read the audio
frames, to do that we need to fill out a structure called multi_buffer_list:
struct multi_buffer_list {
// [...]
int32 return_playback_buffers;
int32 return_playback_channels;
uint32 return_playback_buffer_size;
// Contains the pointer to the start of a given buffer,
// as well as the stride it should take.
buffer_desc ** playback_buffers;
// [...]
int32 return_record_buffers;
int32 return_record_channels;
uint32 return_record_buffer_size;
buffer_desc ** record_buffers;
// [...]
};
We currently specify 2 playback buffers, 1024 frames per buffer, to handle
audio streams. The number of channels is specified in the chmap_query or
defaulting to stereo if no channel maps are given by the device.
WebKit is split into several processes. One of these processes is the browser itself. In my case, this is MiniBrowser, but, hopefully, in the future, it is WebPositive. Since browsers can have any name, WebKit refers to this process as the UIProcess. And, indeed, that process is mainly responsible for the UI. Our port will also be using two other processes: NetworkProcess and WebProcess. Unsurprisingly, NetworkProcess does the networking. WebProcess does all of the work associated with a single web page. For example, it is responsible for running JavaScript and does most of the work for rendering the web page. There is one WebProcess for each web page.
When the coding period began I was expecting to publish a progress report every week. However, we’ve reached the end
of the first month of the coding period and this is my first update: This probably tells that there hasn’t been as
much progress as I expected, although progress have been made.
What works
The library was one of the first things I got done, because it consists of very portable
code, which made it very easy to port, while allowing me to test the (still reduced) driver
capabilities much easier as I could use already existing code examples for NVMM instead of
trying to talk directly to the driver.
Enhancing the Find Panel: A Comprehensive Update
Introduction
Hi there everyone. Since I made my first contribution to the project, I thought making a blog post about it would be helpful. I’m excited to know your thoughts on the changes that have been made to the Find Panel. Most of the current changes are made with ease of use kept in mind.
These updates include the addition of a Menu Bar and the migration of the more-options section into this Menu Bar. This blog post details all the changes and how they are intended to be used.
Project status overview
Despite being a bit silent on the blogs, the project is still alive and kicking.
Completed tasks
I have completed a port of the
gdbserver component of GDB 14.
The port has the full capability of a regular gdbserver port, including:
- Attaching to new and existing processes.
- Manipulating CPU and memory state.
- Reading loaded libraries and symbol information.
- Setting breakpoints.
- Receiving events about breakpoints, teams, threads, images, and syscalls.
Connected to a GDB frontend on a compatible ELF-based system, gdbserver provides a nearly seamless
debugging experience. With the correct configurations, Haiku C/C++ applications can be built on
VSCode, deployed to Haiku, then debugged with the IDE’s UI through gdbserver.
intro
Hello, once again! It’s been a month since the last update, so here we go.
Good news, there is active development of the virtio sound driver for Haiku.
Key progress includes assigning channel maps to their respective streams and
integrating PCM stream scanning.
Additionally, efforts have focused on modularizing the driver, ensuring
compliance with Haiku’s coding standards, and laying the groundwork for further
enhancements to functionality. While progress has been substantial, there are
still areas requiring refinement as we continue to expand the driver’s
capabilities.
