We could get rid of libpsl-native.so
iSazonov opened this issue · 2 comments
Inspired by dotnet/runtime#24271 (comment)
There is a link to a prototype using libSystem.Native.so:
https://github.com/ericstj/sample-code/blob/e0efc3458f0a68bdf2f69be7a2e154386939ff81/symLinkConfig/Interop/Unix/Interop.Libraries.cs#L9
and using in a code:
https://github.com/ericstj/sample-code/blob/e0efc3458f0a68bdf2f69be7a2e154386939ff81/symLinkConfig/Interop/Unix/Interop.ReadLink.cs#L23-L24
PowerShell libpsl-native.so is stable and libSystem.Native.so has most of libpsl-native.so API.
I suppose the MSFT PowerShell team could have an internal partner contract with the .Net team, move additional API from libpsl-native.so to libSystem.Native.so and remove libpsl-native.so at all.
I would expect this to reduce PowerShell support costs. For example, we will automatically get support for all systems that are supported by .Net.
(Even if the .Net team creates a more modern replacement for this libSystem.Native.so, then PowerShell will be able to use that as well.)
Hey, that's a good idea. Definitely warrants some investigation. Thanks @iSazonov!
I saw a long history in .Net repository about using Mono achievements to pinvokes, some preparation PRs for this and a design document.
But I see nothing about the work in current .Net 6.0 milestone https://themesof.net/
If they have plans to continue this work in the next cycle, then most likely they will not want to give access to this libSystem.Native.so library, but they can offer something better and modern.
Make sense to open new issue to discuss this in .Net repo or you @andschwa will do this internally?
Tracking Themes, Epics, User stories and Issues for the next phase of .NET runtime development