-
-
Notifications
You must be signed in to change notification settings - Fork 79
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
Expose native "utilities" like CRC32 calculation, SHA-1, SHA-256 #648
Comments
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Not stale! |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Still Valid |
I found SUPPORT_ComputeCRC and lots of crypto in mbedtls. |
They are (I think) existing methods in the native RTOS for most (if not all) boards, so they need exposing to the managed layer. I guess the question is, whether that is in corlib, or another "helper" lib... In all cases, it needs exposed in the managed layer to be truly useful... BTW, this could be extended (and utility libs exist on the managed layer for things like generating them for connection to Azure when using AMQP). |
I guess this is an example... https://github.com/networkfusion/NetMfMqttClient/blob/master/src/Gadgeteermqtt/SHA.cs |
As the description above tried to explain: the goal is to expose the various utilities that are already available in the native part of the code to C#, thus saving the trouble to added them in their C# form. Not to mention the incurred penalty duplicating code that's already there and with an implementation with less performance. Worth noting that this is NOT an excuse to add new stuff on the native code, rather expose what's already there. The most basic crypto functions, along with CRC32 are available has hardware implementations in most of mid-high level MCUs, so this becomes available with a minimum cost in code size. Suggest that we continue this conversation in Discord, class-libraries-general channel, perhaps... |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
still active |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Was looking at this and on a quick search on .NET docs, found System.Runtime.Intrinsics It has CRC32, SHA1, SHA256, etc pretty much what we're looking into exposing with this. |
I'm all in favor of moving some elements to native. We also have to check that those are present in all the native platforms. Otherwise for libs like Azure or AWS which are using those won't be able to work properly. And there is bunch of IoT devices using CRC16, CRC32, etc. |
Those are available yes. Actually, that's what prompted all this in the 1st place. |
I'm taking back what I've wrote above... 😊 It seems that most of what we need to have exposed (despite several are in the Intrinsics namespace) is better fitted in Cryptography namespace. The "alien" class there will be CRC32 which doesn't exist on the full framework. But we've done it in the past with other APIs and we'll do it again: extend it with what we have. 😉 |
Turns out that there is a .NET API for CRC32! System.IO.Hashing. |
That's a discovery for me! And a great news. It means we definitely can do all this then. Quite some work ahead but it will bring robustness in all this. |
Create a new C# class library that "taps" into the existing native methods and makes them available to managed apps.
The text was updated successfully, but these errors were encountered: