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.
Very nice writeup, and amazing work!
Process unique identifiers with area_id’s sounds a bit hacky, is that just for .net tests?
Perhaps a better solution should exist in Haiku?
For my Rust cross-compiler builder, I have cobbled together a pkgman tool (in Python) that is designed to work on top of a cross-compiler docker image, and is able to connect to a remote repo, and install packages by name. It does not do any fancy stuff like resolving dependencies, but it is good enough to dynamically download packages from HaikuPorts based on a package name, without having to maintain a list of URLs with the latest versions.
I might be interested, if this is a tool that works for you too, to harden the code a bit more and then add it to the cross-compiler image.
Hack or no hack, they should give you all the kernel support you need to get your dotnet port done. You’re doing an awesome job.
Regarding enumerating mount points, you may want to look at src/bin/df.cpp. It uses BVolume to retrieve all the info needed from a dev_t using the published APIs, which may be simpler than your current approach.
Sorry for the late reply, but yes, I’ve recently made a change to Haiku allowing processes to retrieve the process start time. The area_id hack is now removed.
I will document that in an upcoming blog.
That seems nice, but I am working in a C file. It is possible to move the Haiku implementation to a separate C++ file and consume BVolume, but this adds a bit of complexity to the build system instead.
As long as the approach I’m using does not touch private/unstable APIs then I think this should be cleaner than BVolume since it does not take on any libbe dependencies.
Interesting, I see that your Python implementation is able to parse repo files. Although it seems that the base repo URLs still need to be hardcoded and passed to pkgman.py.
I’m focusing on getting the .NET SDK to work and can hopefully move away from cross-compilation in the (not-so-distant) future.