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
Python should support VxWorks RTOS #76085
Comments
With the trend to use REST APIs between the cloud and the IoT there is increasing interest in Python on embedded devices. Cloud developer’s typical release a reference REST implementation of JSON and/or Python on Linux and leave it to the device developer to adapt it to their platform. While many devices use eLinux, others with IP and/or hard real-time constraints need a commercial RTOS platform. Currently the automake configure explicitly prevents configuration of VxWorks as a build target. I'll provide a pull request referencing this issue with the required changes. |
The following might be relevant to this issue: |
To support a new platform, you need a developer who can support this platform next years, a working buildbot, etc. You can start a discussion on python-dev to get a first feedback. Without a strong support, this issue should be fixed a REJECTED and a patch should be maintainted out of the tree. Since the PR seems small, it should be "easy" to keep a fork of CPython up to date. |
FYI I already started a thread on python-dev: |
I'm quite happy to take on maintainer role for Python on VxWorks, so I think we can get that one solved. Enabling a build bot for cross compile of propitiatory OS presents a number of legal licensing issues that outside my control. And I'll discuss it internally at Wind River. However I think it is in line with where our customers want us to go, so well worth pursuing. I'll keep this pull request active and up to date, till the broader issues you have raised can be resolved. I'll post a proposal on the mailing list after I consulted within Wind River. Many thanks for your interest and support. |
I'm not sure what licensing issues you are talking about, but setting up a buildbot shouldn't normally run into any. As long as you have a license to the run the OS, the fact that you are using it to receive jobs from our build master and run them shouldn't be a problem. You can keep the whole thing behind a firewall in a DMZ: the slave makes outbound connections to pick up its jobs. On the other hand, the logistics of setting up a cross compile buildbot might be a bit complex, I've never done that. You might need specific support from our build master. In any case, the python-buldbots mailing list is the place to talk if you want to/can pursue this. |
As I commented on the PR, I think this PR should not be merged until and if there is a consensus that this support belongs in the standard cpython repo and there is an agreed-upon plan how this platform would be supported on going. I think it needs an approved PEP. We've allowed ourselves in the past to do a long-term disservice to our downstream users by merging in support for platforms that we were not equipped to support. In any case, it would need to wait for 3.8. |
Kuhl, Brian started a new discussion: [Python-Dev] VxWorks and cpython? PR 11968 and PR 12051 are small and reasonable. IMHO we can take decisions on a case by case basic. But WindRiver plans to provide a buildbot and is already showing their will to propose PRs, so it seems like things are moving on. |
Please stop to send new PRs which depend on other PRs which are not merged yet, it becomes too hard to follow :-( Let's focus on first PRs. |
I'm against implementing crypt on top of OpenSSL's DES_crypt. Please don't support the module at all instead of just supporting a completely broken implementation. |
Please stop adding more pull requests, I cannot review too many at the same time. I would prefer to have a limit of 4 open PRs. I don't propose to close existing ones. Just stop to add more :-) |
@vstinner I've informed WRS team of temporarily not creating new PRs in until less than 4 PRs are in the open state. Next we will keep open PRs less than 4. Thanks for your effort on them. |
Please update PR 12670: see my comment there. |
Is it safe to say that there is an now intent to support VxWorks within the main tree, with Wind River agreeing to be primary support? And this ticket has become a tracking ticket for the status on getting it there, small PR by small PR plus buildbot? |
@Jim.Jewett Yes. We have got most modules passed testing locally. Now we want to get the patches upstream. So VxWorks platform can be officially supported. |
test comment |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: