[public api] System.Runtime.Environment - OSName("FreeBSD") or OSName("BSD")

[ghuntley]

This issue is to discuss what the final identifier will be within the entire public API surface and what will be the build target identifier that msbuild will use.

https://github.com/dotnet/corefx/issues/1576 started the discussion of wether to use OSName("FreeBSD") vs OSName("BSD") in the unit tests and is recommended reading before progressing with reading this issue. FreeBSD won but it can be easily refactored due to being a non-public contract.

The BSD's (FreeBSD/NetBSD/OpenBSD/DragonFlyBSD) unlike Linux all have different kernels so potentially it might be required to split them out as separate platforms. This might be completely unnecessary whereby the additional BSD's may just work as a direct result of the port team's efforts. There are enough differences between the different BSDs that it could be needed to differentiate between them however.

We have some time before a decision needs to be cemented in as there is a more pressing issue as mentioned by @stephentoub and registered as issue dotnet/corefx#1626

There's what's likely a more pressing issue, which is actually building for FreeBSD. Today, when we need to specialize an assembly for a particular platform, we effectively have three builds, producing three different managed assemblies: Windows, Linux, OSX. Sounds like at least for now we'll need a fourth, FreeBSD. I suggest you start by modifying the build to support an IsFreeBSD property (or just IsBSD of you think there's a high chance that the implementations across BSDs will be the same even with varied kernels) along with the appropriate OSGroup targets. That can then be used in the csproj files as needed to specialize an assembly with FreeBSD-specific code.

I feel uneasy about using either OSName("FreeBSD") (platform fragmentation) or OSName("BSD") (too generic) with the amount of information available at this point in time but obviously a direction needs to be chosen.

@janhenke @josteink (core members of the portteam) have put forward on multiple times that they would prefer FreeBSD and I have no strong preferences in any which direction as long as the future implications are considered carefully because this decision affects the public API surface.

Ultimately advice, direction and a decision will be needed by MSFT on this matter.

note: issue was edited/refactored based on feedback from josenink since original post.

[josteink]

This issue is to discuss what the final identifier will be within the public API.

Just to be absolutely sure we're discussing the same issue: Are you talking about what programmers will ultimately see when invoking System.Environment.OSVersion and specifically System.Environment.OSVersion.Platform ? Or something else?

In the following comment, I'll assume the former, but please correct me if I'm wrong.

For the public API, while we can certainly come up with a technical reason or argument for a specific identifier, I would assume that for something like this, participants from Microsoft will ultimately be the ones who makes the decision. And if so, who?

Or am I wrong? Is coreclr "beyond" that? I've heard things about a wish to blur the lines between external and internal, but I'm not sure how far this process has come nor at what stage we're at right now.

I feel uneasy about using either OSName("FreeBSD") (platform fragmentation) or OSName("BSD") (too generic) but obviously a direction needs to be chosen.

As a programmer, if I were to probe what OS I'm on it's can only be for two reasons:

• I want to include that as textual information in a log, report, or just pop it up in the GUI without doing anything with that information.
• I want to make a programmatic decision about what to do in specific cases for specific values.

For the first case, either value is fine. For second case, it's not.

If I want to probe the OS I'm running on to make runtime-decisions, it may be for whatever reason (filesystem-model, network-implementation/behaviour, service-model, known OS-level tools available to execute, etc).

In that case something like "BSD" will be so generic it provides me with zero use-value. It might as well be null. In that case I'm clearly for "FreeBSD".

[milizhang]

I would vote for "FreeBSD".
From my own experience all these BSDs are quite different today, in terms of both userlands and programming interfaces. They might be able to share some parts of libraries but they should be treated as different platforms.

[ghuntley]

Unless MSFT feels differently on the matter FreeBSD will be the identifier and will be potentially included as part of dotnet/corefx#1999

[ghuntley]

See dotnet/corefx#1999 (comment)

I think it's completely reasonable to use dotnet/corefx#1625 to claim the "FreeBSD"
identifier (I would suggest that we use "FREEBSD" since we put the other
monikers in all caps). Folks that want to do platform detection can use
OSPlatfom.Create("FREEBSD") and I'd be happy if part of bringing up the stack
includes the work to produce a version of System.Runtime.Environment for
FreeBSD that returns true for an OSPlatform name of "FREEBSD". But I don't
think we should feel like we need to add the property right away. The design we
have was built in order to be able to decouple adding property to the surface
area from having an implementation be able to return true for it.

[AlexGhiondea]

@ghuntley can this be closed?

[karelz]

@ghuntley is FreeBSD port ready for this? If yes, can you please submit formal API proposal with the added static field?

[karelz]

Duplicate of dotnet/corefx#23989.