classification
Title: Python should support VxWorks RTOS
Type: enhancement Stage: patch review
Components: Cross-Build Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Alex.Willmer, Brian Kuhl, izbyshev, lukasz.langa, ned.deily, r.david.murray, vstinner
Priority: normal Keywords: patch

Created on 2017-10-30 19:56 by Brian Kuhl, last changed 2019-03-19 09:25 by hliu0.

Pull Requests
URL Status Linked Edit
PR 4179 closed Brian Kuhl, 2017-10-30 20:46
PR 4184 open Brian Kuhl, 2017-10-31 03:13
PR 11951 closed pxinwr, 2019-02-20 03:51
PR 11968 merged pxinwr, 2019-02-21 06:39
PR 12051 merged pxinwr, 2019-02-26 09:58
PR 12118 open pxinwr, 2019-03-01 10:07
PR 12157 open pxinwr, 2019-03-04 08:45
PR 12304 merged pxinwr, 2019-03-13 07:26
PR 12305 open pxinwr, 2019-03-13 09:43
PR 12319 open ysun1, 2019-03-14 07:42
PR 12321 open pxinwr, 2019-03-14 07:55
PR 12394 open lzhao, 2019-03-18 06:33
PR 12428 open hliu0, 2019-03-19 09:25
Messages (12)
msg305249 - (view) Author: Brian Kuhl (Brian Kuhl) * Date: 2017-10-30 19:56
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.
msg305511 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-11-03 21:01
The following might be relevant to this issue:
https://www.python.org/dev/peps/pep-0011/#supporting-platforms
msg305657 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-11-06 16:55
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.
msg305690 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-11-06 23:39
FYI I already started a thread on python-dev:
[Python-Dev] Partial support of a platform
https://mail.python.org/pipermail/python-dev/2017-November/150238.html
msg305869 - (view) Author: Brian Kuhl (Brian Kuhl) * Date: 2017-11-08 16:00
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.
msg305877 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-11-08 16:23
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.
msg315365 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-04-16 19:40
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.
msg336680 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-02-26 14:53
Kuhl, Brian started a new discussion: [Python-Dev] VxWorks and cpython?
https://mail.python.org/pipermail/python-dev/2019-January/156024.html

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.
msg336742 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-02-27 11:09
New changeset 32f5fdd7f4213743fe2f6eedd0fe2108f3157021 by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Add cross-build support for VxWorks RTOS (GH-11968)
https://github.com/python/cpython/commit/32f5fdd7f4213743fe2f6eedd0fe2108f3157021
msg337083 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-03-04 09:02
New changeset f4b0a1c0da80318e0a4f4c70d2722f01ce3512dd by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Add encoding support for VxWorks RTOS (GH-12051)
https://github.com/python/cpython/commit/f4b0a1c0da80318e0a4f4c70d2722f01ce3512dd
msg337867 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-03-13 17:18
New changeset 8b5bdda5b4c418c4a858f183763d0a497170977c by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Adapt the _signal module to VxWorks RTOS (GH-12304)
https://github.com/python/cpython/commit/8b5bdda5b4c418c4a858f183763d0a497170977c
msg337909 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-03-14 10:28
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.
History
Date User Action Args
2019-03-19 09:25:00hliu0setpull_requests: + pull_request12382
2019-03-18 06:33:02lzhaosetpull_requests: + pull_request12349
2019-03-14 10:28:02vstinnersetmessages: + msg337909
2019-03-14 07:55:27pxinwrsetpull_requests: + pull_request12295
2019-03-14 07:42:03ysun1setpull_requests: + pull_request12293
2019-03-13 19:01:26terry.reedysetnosy: - terry.reedy
2019-03-13 17:18:28vstinnersetmessages: + msg337867
2019-03-13 09:43:53pxinwrsetpull_requests: + pull_request12281
2019-03-13 07:26:37pxinwrsetpull_requests: + pull_request12280
2019-03-04 09:02:31vstinnersetmessages: + msg337083
2019-03-04 08:45:09pxinwrsetpull_requests: + pull_request12155
2019-03-02 16:59:16izbyshevsetnosy: + izbyshev
2019-03-01 10:07:22pxinwrsetpull_requests: + pull_request12123
2019-02-27 11:09:35vstinnersetmessages: + msg336742
2019-02-26 14:53:49vstinnersetmessages: + msg336680
2019-02-26 09:58:45pxinwrsetpull_requests: + pull_request12077
2019-02-21 06:39:38pxinwrsetpull_requests: + pull_request11994
2019-02-20 03:51:36pxinwrsetpull_requests: + pull_request11976
2018-04-16 19:40:29ned.deilysetnosy: + lukasz.langa, ned.deily

messages: + msg315365
versions: + Python 3.8, - Python 3.7
2017-11-08 16:23:25r.david.murraysetnosy: + r.david.murray
messages: + msg305877
2017-11-08 16:00:46Brian Kuhlsetmessages: + msg305869
2017-11-06 23:39:05vstinnersetmessages: + msg305690
2017-11-06 16:55:23vstinnersetnosy: + vstinner
messages: + msg305657
2017-11-03 21:01:04terry.reedysetnosy: + terry.reedy
messages: + msg305511
2017-10-31 03:13:38Brian Kuhlsetpull_requests: + pull_request4155
2017-10-30 20:46:47Brian Kuhlsetkeywords: + patch
stage: patch review
pull_requests: + pull_request4149
2017-10-30 19:56:33Brian Kuhlcreate