Tracking issue for illumos and Solaris x86-64 port work

[am11]

Cut from https://github.com/dotnet/runtime/issues/4173.

Given below is a high-level list of work items for Solaris x86-64 port:

• [x] Native configurations (#34756)

• [x] CoreCLR native components (#35173)

  • awaiting next release of libunwind https://github.com/libunwind/libunwind/releases/tag/v1.5-rc1 or higher with changes from https://github.com/libunwind/libunwind/pull/171, for Solaris support.
  • upstream PR was merged, libunwind is updated to 1.5 by @sdmaclea in #36027.

• [ ] PAL tests

  • one test is failing is due to #35362.
  • another one is related to raising thread priority, after lowering it from the same value as a non-root user. this either requires implementation using priocntl(2) directly for SunOS targets, or wait for https://www.illumos.org/issues/4963.

• [x] Libraries native components (#34867)

  • on SmartOS x86_64 with gcc 7x:

    # from runtime repo root
    ./src/libraries/Native/build-native.sh -gcc

• [x] Mono native components (#37560)

  • Full mono (https://github.com/mono/mono) is already available on Solaris, requires some configurations for netcore mono in this repository.

• [x] Installer native components (#34263)

  • on SmartOS x86_64 with gcc 7x:

    # from runtime repo root
    src/installer/corehost/build.sh -commithash $(git rev-parse HEAD) -gcc \
    -apphostver 5.0.0-dev -hostver 5.0.0-dev -fxrver 5.0.0-dev -policyver 5.0.0-dev

• [ ] MSBuild configurations

• [x] CoreCLR managed components (#36266)

• [ ] Libraries managed components

  • Most of the partial classes can be shared with Linux (e.g. by moving it under Unix names) and modifying msbuild configurations.

• [ ] Installer managed components

• [x] CoreCLR tests (#37824)

• [ ] Libraries tests

• [ ] Mono tests

• [ ] Installer tests

• [ ] Packaging configurations

• [x] RID (#37016)

• [x] Cross compilation on Linux (dotnet/arcade#5584, dotnet/dotnet-buildtools-prereqs-docker#324, #37753)

  • as done for other operating systems, e.g. FreeBSD: https://github.com/dotnet/arcade/blob/3443768/eng/common/cross/build-rootfs.sh#L243.
  • script gets mirrored at https://github.com/dotnet/runtime/blob/master/eng/common/cross/build-rootfs.sh.

• [x] SDK (dotnet/sdk#12198)

• [ ] CI hook

  • similar to https://github.com/dotnet/dotnet-buildtools-prereqs-docker/pull/277 and https://github.com/dotnet/runtime/pull/34521
  • external (GitHub Actions) CI has set up using the official illumos docker image: https://github.com/am11/runtime/blob/feature/sunos/ci/.github/workflows/main.yml
  • example run: https://github.com/am11/runtime/actions/runs/145127885
  • on tag push, it creates a GitHub release and upload artifacts (files under Shipping directory), e..g. https://github.com/am11/runtime/releases/tag/5.0.0-dev.1

[gwr]

Also need: https://github.com/dotnet/runtime/pull/105424 before this passes all tests.

[gwr]

These two PRs are waiting on final review and integration:

• SunOS process and thread support #105403

• Fix MaxWorkingSet_GetNotStarted_ThrowsInvalidOperationException #105424

With the changes in these two PRs, illumos works well enough to pass most tests.

[am11]

These two PRs are waiting on final review and integration:

If you look around at the opened PRs, 10.0 changes are lining up and maintainers are busy finalizing 9.0 release. These delays (especially for new ports) happen during this time of the year. All the opened PRs pending .NET 9 -> 10 switch over will be reviewed in coming weeks.

Meanwhile, if you have capacity and want to stay productive, there are two remaining libs need porting System.Net.Security and System.IO.FileSystem.Watcher. This will complete the shared framework requirement (which dotnet/sdk and dotnet/msbuild rely on).

[AustinWise]

On the idea of various ways to do async IO mentioned in the FreeBSD issue linked above this comment: /dev/poll, Event Ports, and AIO were mentioned. Another possibility is the epoll emulation that has been in illumos since 2015. I think it would make sense to try to use the existing epoll code for SystemNative_WaitForSocketEvents and in other places before implementing a new async IO path.

[am11]

Completely agree. These are mainly the showstoppers, the quickest way to complete the ShareFX functionality is preferred so we can move to enable source build.

[gwr]

Meanwhile, if you have capacity and want to stay productive, there are two remaining libs need porting System.Net.Security and System.IO.FileSystem.Watcher. This will complete the shared framework requirement (which dotnet/sdk and dotnet/msbuild rely on).

OK, thanks. I'm working on System.IO.FileSystem.Watcher One question on that: How important is "sub-tree" watch? If we only got events for in the current directory, would that be good enough for applications? (assuming we were to opt out of test cases related to changes in child paths)

[am11]

I think we can start with simple solution to unblock the main APIs or to "get by". However, sub-tree watching is highly important for many advanced real world use-cases like development tools, IDEs, and build systems that need to monitor complex directory trees.