Hi Victor,
I think we can come up with some sort of strategy that will work for everyone. 
I'll ask about the SSH access; and if that runs up against a corporate 
roadblock, I will explore some other alternative. 

Is there a good place to document "Python on VxWorks" ?
The changes to Python are not large, I've kept the pull request from last 
year's POC active. The changed files provide a good summary of the scope.
https://github.com/python/cpython/pull/4184/files
However, based on the POC we've gone back and improved VxWorks, so the some of 
the uglier bits, in libraries like submodule, won't be needed.
These will be in the next release of VxWorks. 

However we let automake and setup.py do much of the work for us, so where 
VxWorks  does not have support for something, it's not obvious.
A public document would go a long way to filling in those details, something 
much more detailed than  my glib "VxWorks is almost POSIX" in the pull request. 
 

Other challenges; 
* VxWorks is cross-compiled on both Linux and Windows. ( currently with clang 
and gcc)
* Supported on ARM,  PowerPC and Intel processors
* 32bit and 64bit builds 
* A constantly evolving set of reference boards (or BSPs)   
https://marketplace.windriver.com/index.php?bsp&on=list&type=platform&value=VxWorks:%207%20-%20Wind%20River%20Workbench%204.0

I don't think we need a buildbot for every board.  I'm thinking a 1/2 dozen to 
cover ARM, PPC and IA with both a 32bit and 64 bit build?
We have a bit of chicken and egg problem right now, a buildbot will always fail 
until there's some basic VxWorks support added. 

Do we set them up, and just let them fail, till enough PRs are accepted to make 
it build?

Brian

> -----Original Message-----
> From: Victor Stinner [mailto:vstin...@redhat.com]
> Sent: Wednesday, January 09, 2019 6:43 PM
> To: Christian Heimes
> Cc: Guido van Rossum; Kuhl, Brian; python-dev@python.org
> Subject: Re: [Python-Dev] VxWorks and cpython?
> 
> Le mer. 9 janv. 2019 à 18:16, Christian Heimes <christ...@python.org> a écrit 
> :
> > It's a PEP. The process and expectations for platform are explained in
> > PEP 11, https://www.python.org/dev/peps/pep-0011/
> 
> I also wrote some information in my website:
> https://pythondev.readthedocs.io/platforms.html
> 
> > If possible it would also be helpful to get SSH access to some VxWorks
> > machines for core devs. I know that Victor likes to dig into rare
> > corner cases and help to debug exotic platforms.
> 
> The best case to get a full support is to have one core developer responsible 
> of
> handling all bugs specific to the platform.
> 
> As a core developer, I'm never comfortable to merge a change specific to a
> platform if I'm not able to validate it manually myself. I trust no one, not 
> even
> myself (I know well that I do frequently mistakes!), so I prefer to always 
> double
> check changes before merging them ;-)
> 
> In the meanwhile, I would say that we can only offer "best effort"
> support. Fix reports bugs and do our best in our limited time.
> 
> Someone has to take the work done to port Python on VxWorks and write small
> pull requests. These PRs should be reviewed one by one to make sure that it's
> the correct way to fix an issue. Be prepared that it can take several months 
> even
> if all these changes look obvious to *you*. Core developers have limited time
> and many prefer to focus on the platforms that they are using, not worry about
> a platform they never heard about... I can have a look at such PRs.
> 
> It would also help to have a documentation somewhere about "Python on
> VxWorks". Pointers to VxWorks (general info, developers info), pointers to 
> your
> port, current status of the port, etc.
> 
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to