add FreeBSD to Common/tests/XunitTraitsDiscoverers/PlatformID.cs?

[ghuntley]

Greetings,

With FreeBSD becoming a reality over in the CoreCLR repository I have started combing for references within CoreFX that will potentially need changing. PlatformID.cs has caught my eye and it looks like this is used to target if unit test(s) should be enabled/disabled on a particular platform:

This issue is a RFC to discuss as to how PlatformID should be modified to cater for FreeBSD and how to handle other BSD variants that use different kernels.

https://github.com/dotnet/corefx/blob/master/src/Common/tests/XunitTraitsDiscoverers/PlatformID.cs is currently:

[Flags]
public enum PlatformID
{
    Windows = 1,
    Linux = 2,
    OSX = 4,
    Any = Windows | Linux | OSX
}

Whilst OSX due to the family lineage could be argued to be a BSD it makes more sense to specifically purpose a flag just for FreeBSD as every release of OSX drifts further and further away from the original origins. Thus add FreeBSD = 8

[Flags]
public enum PlatformID
{
    Windows = 1,
    Linux = 2,
    OSX = 4,
    FreeBSD = 8,
    Any = Windows | Linux | OSX | FreeBSD
}

If a team forms around OpenBSD, NetBSD or DragonFlyBSD and actual product ships then we could rename FreeBSD to BSD similar to below:

[Flags]
public enum PlatformID
{
    Windows = 1,
    Linux = 2,
    OSX = 4,
    BSD = 8,
    Any = Windows | Linux | OSX | BSD
}

However unlike linux, FreeBSD/NetBSD/DragonFlyBSD all have different kernels so potentially it might be required to split them out as separate platforms as follows.

[Flags]
public enum PlatformID
{
    Windows = 1,
    Linux = 2,
    OSX = 4,
    FreeBSD = 8,
    OpenBSD = 16, 
    NetBSD = 32, 
    DragonFlyBSD = 64, 
    Any = Windows | Linux | OSX | FreeBSD | OpenBSD | DragonFlyBSD
}

/cc: other members of portteam - @kangaroo, @josteink, @janhenke, @ajensenwaud
/bcc: @richlander - we need a label created for FreeBSD on this repo and this issue tagged.

[stephentoub]

Thanks, @ghuntley.

This is test code, so we can be very flexible with such APIs and adapt them at will. I suggest in this case we do so on an as-needed basis rather than trying to be proactive about it and guessing what situations we may encounter. The first time we hit an issue that requires us to disable or specialize a test, we can add BSD to the enum. Then if we get to a point where that needs to be split apart by flavor of BSD, we can do so and revisit each usage site, which we'd almost certainly need/wasn't to do anyway. This ID is mostly used to identify problematic tests, and I suspect that any test which is problematic on FreeBSD will also be problematic on others.

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.

[stephentoub]

That's said, I realize we'll very likely need to disable on FreeBSD any tests currently disabled on Linux and OSX, so we'll probably need this fairly soon. In which case, feel free to submit a PR to add it. :)

[stephentoub]

ps I submitted dotnet/corefx#1578 to help simplify this a bit. With this, you can add a BSD or FreeBSD item to the enum, modify the AnyUnix enum value to include it, and then most of the tests that should be disabled will be by default.

[ghuntley]

@janhenke has a preference to go with FreeBSD for both PlatformID and OSGroup as safety measure in case of compatibility the other BSD kernels are incompatible. We can always take a rename if the other BSD's turn out to be compatible.

Once dotnet/corefx#1578 is merged will do a PR for PlatformID and then open up a separate issue for producing managed assemblies for FreeBSD.

ps: Our development infrastructure is VMware based which means other operating systems - BSD (or even Solaris) are a possibility. The CI infrastructure runs on Microsoft Azure whereby supported platforms are quite restricted - we are lucky that FreeBSD works. This limitation will prevent other portteams being as successful as the FreeBSD team.

[stephentoub]

Ok. Sounds good.

[josteink]

I agree with @ghuntley and @janhenke. If time shows that our assumptions were false, it should be easy enough to change.

[stephentoub]

That's fine. My primary point was exactly that, that there's lots of flexibility here with regards to test code and being able to change it at will. We'll have much less flexibility in changing course with public APIs, e.g. once we add "FreeBSD" and whatnot to https://github.com/dotnet/corefx/tree/master/src/System.Runtime.Environment/src, we'll be locked into it.

[ghuntley]

Resolved.

FreeBSD as a PlatformID has been added to buildtools by @jasonwilliams200OK (thanks!) - see commit dotnet/buildtools@e30b1ce