Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[QUIC] Adopted msquic generated interop #68288

Merged
merged 28 commits into from
May 5, 2022

Conversation

ManickaP
Copy link
Member

Fixes #67377, #67301

cc @nibanks

@ghost
Copy link

ghost commented Apr 20, 2022

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

Fixes #67377, #67301

cc @nibanks

Author: ManickaP
Assignees: -
Labels:

area-System.Net.Quic

Milestone: -


namespace Microsoft.Quic
{
internal class MsQuicException : QuicException
Copy link
Member Author

@ManickaP ManickaP Apr 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not 100% convinced about this, we could merge this with QuicException. I just wanted to keep msquic error based exception separate. Or can deal with this when we discus more broader exception topics like #55619 and #56954


namespace System.Net.Quic.Implementations.MsQuic.Internal
{
internal abstract class MsQuicSafeHandle : SafeHandle
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extracted some similar code from all our SafeHandle implementations. We don't actually need SafeHandles atm since we're working directly with native pointers in p/invokes. But we discussed using reference counting for stream-connection lifetime relation so I'm keeping this in for now.

@@ -0,0 +1,191 @@
#pragma warning disable IDE0073
//
// Copyright (c) Microsoft Corporation.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@samsp-msft do we have any guidelines about including other code in our repo?
I workaround the compilation with warning disable but I got a feeling there might be some legal implications since dotnet belongs to the foundation and not Microsoft.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already mentioned I think we should find a way you don't have to check this file in, but if you do, since it's MIT licensed, that practically means you can take it and do what you want with it, which I believe, means you could change it to your normal .NET license header.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The general guideline is at https://github.com/dotnet/runtime/blob/main/CONTRIBUTING.md#copying-files-from-other-projects

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the #pragma warning disable OK in this case or is there another way to suppress the error if I'm to leave the original notice.

Also the example file has our notice:

// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.

So should I start with our notice and then the original and then info about where it came and what changes I've made?

I'll add third party notice as well, I'm mostly asking about the specifics of the imported files.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it is a verbatim copy of the file from the other project without any changes, it is better to leave it intact, without the .NET Foundation header. It is easier for consuming updates.

We have a lot of similar cases under https://github.com/dotnet/runtime/tree/main/src/native/external . Notice that all files in the subdirectories are verbatim copies of other projects, without the .NET Foundation header.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is not verbatim copy, right, @ManickaP? From the original list of changes, most made it to MsQuic, but we still change the type of exception thrown from ThrowIfFailure.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not verbatim.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whats still missing? I'm happy to make it verbatim. I thought I got everything, but might have missed something.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what I missed. Let me PR it into MsQuic. The only missing thing will be using System.Net.Quic, but that isn't actually needed from what I see.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah. I see theres also some differences in MsQuicException.cs, but those I won't be able to fully solve. I'll get close though.

@rzikm
Copy link
Member

rzikm commented Apr 20, 2022

Suppose there is a change in MsQuic API in the future, what actions are needed to update the interop layer from our end? In other words, what changes did you make to the generated files so that they can be used by the runtime?

@ManickaP
Copy link
Member Author

Suppose there is a change in MsQuic API in the future, what actions are needed to update the interop layer from our end? In other words, what changes did you make to the generated files so that they can be used by the runtime?

3 things:

  • #pragma warning disable/restore
  • making all types internal instead of public
  • QuicException -> MsQuicException

I strongly recommend comparing the files in some visual diff tool (e.g. beyond compare) to see the changes.

Also if anyone has a better idea how to consume it with less "manual work", I'm all ears.

@ManickaP ManickaP force-pushed the mapichov/quic_interop branch from 30dfdb9 to 059c3d4 Compare May 3, 2022 16:57
@ManickaP
Copy link
Member Author

ManickaP commented May 3, 2022

@jkotas Thanks a lot for taking the time and helping me with the buffers! I really appreciate it.

Copy link

@nibanks nibanks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Copy link
Member

@CarnaViire CarnaViire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks! 🚀

@ManickaP
Copy link
Member Author

ManickaP commented May 5, 2022

Failures unrelated.

@ManickaP ManickaP merged commit 992b395 into dotnet:main May 5, 2022
@ManickaP ManickaP deleted the mapichov/quic_interop branch May 5, 2022 10:32
jkotas added a commit that referenced this pull request May 5, 2022
jkotas added a commit that referenced this pull request May 6, 2022
ManickaP added a commit to ManickaP/runtime that referenced this pull request May 7, 2022
ManickaP added a commit that referenced this pull request May 11, 2022
* Revert "Revert "[QUIC] Adopted msquic generated interop (#68288)" (#68940)"

This reverts commit 4820674.

* Exclude S.N.Quic from Mono AOT

* Fix #68954
@ghost ghost locked as resolved and limited conversation to collaborators Jun 4, 2022
@karelz karelz added this to the 7.0.0 milestone Jul 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[QUIC] Adopt msquic generated interop layer
7 participants