-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Conversation
Tagging subscribers to this area: @dotnet/ncl |
|
||
namespace Microsoft.Quic | ||
{ | ||
internal class MsQuicException : QuicException |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
namespace System.Net.Quic.Implementations.MsQuic.Internal | ||
{ | ||
internal abstract class MsQuicSafeHandle : SafeHandle |
There was a problem hiding this comment.
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 SafeHandle
s 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
-
There needs to be some details captured on where this file came from and what modifications were done to it. Either add it to the top of the file or add it in a separate file.
-
This should be added to https://github.com/dotnet/runtime/blob/main/THIRD-PARTY-NOTICES.TXT
There was a problem hiding this comment.
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:
runtime/src/libraries/System.Private.CoreLib/src/System/Globalization/IdnMapping.cs
Lines 1 to 2 in 0ae6b95
// 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not verbatim.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicListener.cs
Outdated
Show resolved
Hide resolved
…ons/MsQuic/MsQuicListener.cs
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Internal/MsQuicApi.cs
Outdated
Show resolved
Hide resolved
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:
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. |
...braries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Internal/MsQuicBuffers.cs
Outdated
Show resolved
Hide resolved
30dfdb9
to
059c3d4
Compare
@jkotas Thanks a lot for taking the time and helping me with the buffers! I really appreciate it. |
...braries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Internal/MsQuicBuffers.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks! 🚀
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Internal/MsQuicApi.cs
Outdated
Show resolved
Hide resolved
...braries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Internal/MsQuicBuffers.cs
Outdated
Show resolved
Hide resolved
...braries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Internal/MsQuicBuffers.cs
Outdated
Show resolved
Hide resolved
Failures unrelated. |
…" (dotnet#68940)" This reverts commit 4820674.
Fixes #67377, #67301
cc @nibanks