More updates on the TUN Driver development!
So What’s Been Happening?
Thankfully I’ve been able to get a lot more done on the driver this week with finishing the write/sending functionality of the driver and I am currently on the reading/receiving functionality which is getting close to being done. At first I tried to implement a solution in the networking interface (tun.cpp) that didn’t use iovecs but that just caught up to me in the end and it was just significantly easier to copy and paste the code from ethernet.cpp’s send/receive functions as that is something that works a lot better than what I was implementing. Me and my mentors also decided on using the already made BufferQueue data structure for holding the data in the driver itself since it would just be plain easier to make the data parameter, when using read from a interface, a straight up net_buffer packet that it can immediately be read back and just use the net_buffer_module_info structs read function member to get the byte stream information that any application needs. The main roadblock I have with the read functionality is using semaphores correctly to stop the networking stack from continuously reading data that isn’t there. As of writing this update, I am able to make read blocking but I am testing different ways I can release the semaphore for it to read data properly. Big shoutout to PulkoMandy and Korli for helping me with this issue!
While the change request to add reference images was being reviewed, I started working on ticket #18415, which suggests adding shear and perspective transformations. I decided to implement the perspective transformation since I still need to figure out which way I’m going to implement the shear transformation. Hopefully the experience in implementing the perspective transformation will give me information that will help me decide how to implement the shear transformation.
Handmaus provided two reasons in the ticket for why the perspective transformation would be useful. One example is Patchbay’s icon.
Intro
Hello again everyone! I wanted to write a long overdue update on how everything is going and what I’ve been learning over the past couple of weeks. Due to how my semester didn’t actually end until the 16th, progress has been relatively slow but now that I have more time I can get started on more things with this project.
Understanding the Project Better
(If I get anything wrong about anything I am about to say, please correct me!)
First things first, what are the actual specifics of what a TUN driver is (since I didn’t go over it in detail last time)? TUN drivers are essentially virtual network interfaces and and a driver that is typically used to establish communication between the operating system and user-space applications. For the network interface in specific, it is a virtual point-to-point connection that works at the IP level of the networking stack and routes all outgoing packets on the system through it where these packets are then sent to the driver. Looking at the driver element, you use your normal write and read syscalls on the driver to emulate the sending and receiving behavior respectfully. You can think of a TUN driver as part of the emulation of an IP interface.
As is the usual way of things, the monthly Activity Report is hereby combined with my Contract Report.
This report covers hrev56962 through hrev57061. It was quite a busy month!
I have fixed three memory leaks. Before, leak_analyser.sh found 75 leaks from simply opening and closing Icon-O-Matic. It now reports only 27.
I am now planning to implement a new shape type called “reference images”. This implements ticket #2748. As discussed in the ticket, having a reference image in the background greatly assists in vectorizing it. Reference images are just for reference. They will not be exported to the final HVIF file.
The coding period has started today! In the last blog post related to GSOC, I said “Here are the plans that I currently have. As with all plans, they are subject to change.” They did indeed change since I found a tool to find memory leaks.
Before I was accepted into GSOC, I had been thinking about porting AddressSanitizer to Haiku to find memory leaks. I decided against it. During the community bonding period, I found a file called leak_analyser.sh, which was made for finding memory leaks, exactly like AddressSanitizer! It was a good thing I had decided against porting AddressSanitizer to Haiku. I now want to work on getting rid of the memory leaks from Icon-O-Matic.
Project status overview
Completed tasks
The .NET SDK has been ported to Haiku after a few hacks. .NET on Haiku now has the ability to run
Roslyn and build a simple console application.
.NET latest builds for Haiku are being provided at
trungnt2910/dotnet-builds. You can follow the
instructions there to install and try out .NET.
Current plans
Before proceeding to the next step, I want to ensure the stability of the current SDK by
bootstrapping .NET on Haiku.
In 2010-2011, mmlr created a new memory allocator: the guarded heap memory allocator. This allocator helps detect various bugs such as writing past the end of allocated memory, reading uninitialized memory, and freeing freed memory. These uses are detailed in “Using malloc_debug to Find Memory Related Bugs”. Later, in 2015, mmlr had a new project: updating the memory allocator to be able to report memory leaks.
To use this feature, start by loading libroot_debug.so instead of libroot.so. This can be done using the LD_PRELOAD environment variable. Once loaded, the MALLOC_DEBUG environment variable can be used to set various options. PulkoMandy added some notes to the end of “Using malloc_debug to Find Memory Related Bugs” describing what options are available. Relevant to finding memory leaks are enabling the guarded heap with g, dumping memory that is still allocated on exit (most of which should have been freed before the program exited and are memory leaks) with e, and telling it to show a stack trace with up to 50 items with s50. Putting it all together, the command to run a program with memory leak detection is LD_PRELOAD=libroot_debug.so MALLOC_DEBUG=ges50 program.
It is barely a week since the start of GSoC, but there has been so much progress on this port.
Ideally, this progress should be coupled with some documentation before my brain’s garbage
collector reclaims the reasoning, so that future maintainers can have an easier time rebasing
and porting newer versions of .NET.
Project status overview
Completed tasks
My current port
has achieved all the tasks that the partial .NET 7 port did last summer, including:
As is the usual way of things, the monthly Activity Report is hereby combined with my Contract Report.
This report covers hrev56888 through hrev56961.
