-
Notifications
You must be signed in to change notification settings - Fork 581
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
Consider moving System.IO.Ports package to dotnet/iot repo #1797
Comments
@danmoseley you are right, as networking is widely used to communicate across machines, Serial is mainly used in IoT scenarios or with older hardware. So, makes sense to have it with .NET IoT . |
Sounds reasonable. dotnet/runtime is getting so much attention that these smaller libraries quickly get out of focus and issues land on the huge pile of open tasks. I have moved parts from one repository to another (including history) before, so that is possible. @joperezr I believe this change would also require changing the signing key for System.IO.Ports, too. But since this one used to be a core library, do you see any issue here? |
The
Above them you can then write application-specific protocols. The problem with moving the I am not currently happy with the
|
Seems I've put RX and TX pins on the test board so we should be able to even finally run automated tests for that library (see https://github.com/dotnet/iot/tree/main/src/System.Device.Gpio.Tests for reference) - I can't remember if I've soldered that header though so it might be a bit of work for @joperezr or someone else in the campus 😄 (or me whenever I visit) looking at the picture I made it's most likely not soldered |
IIRC S.IO.Ports has a native component on it, where the rest of the IoT repo is managed only so that is one potential concern. I'm not opposed to the move, but as part of the move we could consider the possibility of re-writing the native part to be managed as well, which should make it a much better story for CI, build pipelines, packaging, and toolset dependencies in order to work on the repo. @krwq how possible would it be to make S.IO.Ports managed-only? |
Should be possible but I think there were couple of constants which were problematic and I'm not 100% sure they are the same between OS-es. @wfurt might have more details on that |
The constants are definitely platform specific. For example Termios part is another story. that is part of "libc" and that on Linux can be either glibc or it can be musl (e.g. Alpine) Managed PAL is still probably possible but it going to tedious - at least initially. The good part is that the serial ports did not changed that much in last few decades. If we move the code to IOT we can possibly consider better API. While the |
@wfurt Just to be clear, as I wrote above in this thread, I am favorable to a brand new API in this repo. This is why I stressed about:
|
I guess the platform specific will have to stay. Now, we may not need to have a specific native pet for each platform. If we do it will be for higher performance reasons. But looking at a serial port our days, even open at 1M, any platform will support this without issue. And I agree with @raffaeler, it is a great opportunity to modernize the API by adding what is missing. I would still keep the current ones and add new once. I dislike the idea of having 2 packages doing the same thing with different API. |
Cc @dotnet/area-system-io and @stephentoub in case either have thoughts here |
I read the issue description and the comment, but I'm not seeing what significant value moving it would bring. Seems like it'd just be work for little reward? I'm skeptical just moving it to a different repo would somehow significantly increase investment in the library. |
My assumption is that in this repo there is an active community that is passionate about serial ports. But, it would still have to have the same compat bar; so the idea of creating a new library that could move faster may make more sense. |
We spoke about this topic in our last 2 IoT community standups. In general, here are some of the conclusions we came up with in consensus:
|
💯👍 |
Feel free to re-title or replace this issue if the working proposal is now to create a new package. (I have no opinion -- was just looking for options to revitalize our .NET API for serial ports. ) |
I think #1832 and discussion above now makes this issue redundant so I will close it. I notice @raffaeler your comment above that more is required than serial port support. I wonder whether more issues are warranted for those. Anyway, I"ll close this. Thanks for kicking it off! |
I opened the issue after our weekly triage discussion. We all agreed that a new API was more than desirable. Also consider that the IoT world is dominated by python. If you want to attract people from that side, we have to provide a first-class support for the serial port which is commonly used to talk with Arduinos and many other boards. And I strongly believe that we can do a better job. |
This package does not get a lot of attention in dotnet/runtime, partly because one typically needs particular - sometimes very specific - hardware to test it. Also because of that reason, it gets little value from automated test coverage in that repo: most tests are skipped. The code is not much changed from .NET Framework except for adding Unix support.
Serial port seems to have stronger affinity to IOT scenarios, and to the community in this repo, who in many cases may be set up to test it out locally. It would be easier to keep it up to date with the latest hardware and scenarios.
We should consider migrating the package here. Either shipping future versions from here (preferably) or dead ending the package in dotnet/runtime, and shipping from here with a new identity (the System.Data.SqlClient/Microsoft.SqlClient model). It would bring over about 20 or so open issues/requests on it with it.
@richlander shared that he has no objection in principle. I believe @ericstj indicated that it would be technically possible, but we didn't work through the details. Packages from this repo are a little different.
Opening this issue to trigger discussion.
cc @krwq @dotnet/area-system.io @terrajobst
The text was updated successfully, but these errors were encountered: