EPICS Core Developer Workshop
6-8 June, 2017
FRIB, MSU, Lansing, Michigan
Meeting Indico Website
Co-located with the CS-Studio Face-to-Face Meeting
09:00 - 10:30 First session
10:30 - 11:00 Morning Break
11:00 - 12:30 Second session
12:30 - 13:30 Lunch Break
13:30 - 15:00 Third session
15:00 - 15:30 Afternoon Break
15:30 - 17:00 Fourth session
On Thursday there will be no Fourth session, we may even finish at lunchtime
Overall goal of the combined WG meeting is to assert that EPICS 7 and CS-Studio can be presented as a consistent package. End users who download EPICS 7 and CS-Studio will be able to run IOCs with both a Channel Access and PVAccess server. They can use BOY, Display Builder, PVTree, .. with either protocol, and there is an image widget that can display area detector images.
Generally went very well, introducing basics of ‘pvget’, how to use pva:// instead of Channel Access in CS-Studio Display Builder, python client and server for pva.
Document: See `EPICS Training in Osaka` (Instructions for downloading VM, outline of training with examples) and associated documents in https://drive.google.com/drive/folders/0Bwa7KMoZ5dT5ZnpKTGNESDNXZlk
V4 libs are looking for owner. JCA/CAJ still Mercurial on SourceForge.
Can all be in git on github?
What’s the CS-Studio plan for handling data sources? pvManager? Other interfaces? Who will be maintaining the pvAccess / normativeTypes plugs for those interfaces?
In no particular order yet, please add more as you think of them
Submodules to include (C/C++) [final organization may be different]:
From existing Base V3:
At the last F2F meeting, we had these as:
From EPICS V4:
Present: AJ, RL, MK(onrad), GS, MD(alesio), KK, EB, KS, Anton Derbenev, SH, SV, KV, MK, MD, BD, AA.
AJ: Invited set of joint topics to be discussed from the CSS group.
KK: Discussed V4 training from the recent EPICS meeting in Japan.
KK: a possibility to choose to use pvmanager, or vtype.pv
KS: could use formula function, widget w/ script
KK: need something to support like custom structure
SH: structure could site specific, does not have to be the one the community need to use
RL: adding to KK’s point @ EPICS meeting, VM got lots of interest, works very well. We seem to have a nice baseline for a one day training now.
RL: pvAccess is missing Access Security authorization messages from the server to the client about current permissions (read/write) and permission changes.
MD: Nothing machine-parsable in the status codes that get returned.
AJ: Topics list please…
KK: Agreed we need authZ notification in the API across the network.
RL: Granularity needs to go down to fields, which CA handles. Groups in QSRV will have similar issues.
KS: Security aspects (authZ/authN) of RPCs for my CSS clients. Could use more documentation on PVA classes, PVstructures and NTutil APIs. Currently reading an NTTable is 50-60 lines of code.
MK: In a joint session can you give more examples what you’re looking for.
KS: Can show examples.
RL: Request from an ITER developer for a way to map user structures to pvData structures using annotations (in Java).
KS: Do we still need both VTypes and NTTypes?
EB: Slightly different purposes, shouldn’t have to include display things in NTTypes, which VTypes are for.
KK: Removing VTypes would be of interest to us.
KS: Would want NTTypes API to be more java-intuitive.
AJ+MK: Describing the difference between put and put_callback operations and why the top-level API needs to be able to make both types. This is not currently possible on a system that uses the pvAccess API but CA over the network (CA provider for pvAccess API currently always uses put-callback, even when plain put is requested).
MD: Cleaning up the CA provider would be a good thing to do, it doesn’t follow the requester API rules properly. Can get data corruption when monitoring with the CA provider (same code as above).
MK: Aware of both issues, try to fix for EPICS 7.
AJ: Looking for maintainership for the Java implementations. Any help from CSS group?
RL: Matej is no longer available for significant effort at the kind of level needed. Code reviews is a good way to start contributing, even for less experienced people.
BD: ESS cares about the Java stack.
KS: Diamond is also very heavily using Java at their beamlines.
KK: It might make sense for CSS to take on PVA maintenance, what about CAJ/JCA?
..: Murali has been adding features to CAJ/JCA, e.g. variable length arrays.
MD: Has a git converted repo of the CAJ/JCA with some added features, e.g. name resolution over TCP.
AJ: Should try to combine repo’s on github, under the epics-base project.
AI on RL: Green-light this from CosyLab and work with MD and Murali to merge everything and move to github. (Done. Matej/Cosylab are fine with that approach.)
AI on RL: Check with Murali about that status of his changes and merge. (Done as per 12 June; all changes from Murali are in.)
Next joint session: Wednesday after lunch, 1:30pm.
RL: Gabriele Carcassi would be willing to come for a session Weds or Thurs if we really need him for something, but not just to hear us argue…
Both groups will meet up to go for Lunch today at 11:45.
SV: Not everything fits into the existing NTs; or APS we define types for our needs. We shouldn’t push everybody to use existing NTs or even try to adopt everybody’s types as NTs.
SH: There should be a limited number of NTs; a new type for each type of hardware would be unmaintainable.
SV: We have several different types, designed appropriately for the application.
RL: For digitizers there have been attempts to generalize these. SLAC + Rivers, and CosyLab NDS. Digitizers may make sense for a standard type.
MD: Please stop trying to do device modelling, better discuss what clients exist and how they use this data. For digitizer they need to extract a single X-Y array.
SV: I’ve heard people argue “why are you using your own type rather than adopting this NT” – shouldn’t do that.
MD: Site-specific top level with NTs as sub-structures.
RL: Where does the time-stamp point, pre/post triggers etc.?
RL: For now we are trying to keep the set of NTs small, only consider generalizing with enough examples.
MD: The danger is sites writing local clients, not so much local structures.
RL: Also specific configuration of generic clients.
Resolved: Sites may propose new normative types. The core group will be happy to review such proposals for acceptance as an NT after suitable community discussion.
MD: Only for a top-level NT where every member is another NT.
RL: What structures can QSRV serve?
MD; A structure where every member is either an NTScalar or NTScalarArray. There is no obvious client that could benefit from having a higher level NT for this.
RL: We will need nested structures to support device modelling. My use case is to be able to configure a device in one put.
MD: Device modelling has never worked.
RL: We have been using standard structures for unifying the interfaces to devices for a long time; say 12 channels which are the same for all PSUs for the generic interfacing for HLAs, but each type can have its own type-specific channels as well for engineering purposes.
MD: Ok with adding the ability for QSRV to be able to support deep structures, but might not have time to add it myself.
RL: Embedding AreaDetector NTImage types?
MD: QSRV connects to the database, not to other PVA servers.
RL: We used to have one, but it got removed with no documentation on how to use standard types to do it, which was the argument.
AJ: Refers to above resolution. Could be added.
RL: Ok, but would like to have an example how to do this.
MD: I think you can do this, similar to the Transient Recorder except you have 1 more point on the X array than the Y.
RL: Didn’t seem to work out.
MD: Ahh, missed the 2D qualifier, I retract that.
RL: Will have to discuss this again with my colleague.
MK: Does AreaDetector have support for this? I remember that it might do.
Question about future support for V4 modules: We will release V4 modules separately for building against Base-3.15, possibly against 3.14. QSRV will need 3.15 or newer; grouping needs 3.16. The linkSupport implementation for pvAccess needs 3.16.
Need a table in the documentation showing minimum versions of modules dependencies.
createRequest always fails after first failure: issue #44 in pvDataCPP
MD: I think this is fixed. Added version of global function that throws, replaces class etc.
filter plugin support for pvCopy: pull #46 in pvDataCPP
AJ: Defer to later discussion.
overhaul byteBuffer implementation: pull #45 in pvDataCPP
MD: Tested for months, ready for merge (no reviews?)
MD: Additional changes in private branch:
Field builder, const-safe way to append fields to existing definition. Inject tags for monitor queuing with flow-control
Deprecate utility classes; remove previously deprecated classes. Implement moving monitor API from pvData to pvAccess (monitor.h). Should be transparent.
Invisible: Conditional macros for C++11 keywords final and override.
caProvider support record[block=false]: issue #62 in pvAccessCPP
MK: Fix for the busy record. MK has fix in the Java implementation, no pull request yet.
caProvider monitors broken: issue #63 in pvAccessCPP
MD: If the monitor update rate is high enough, you will get data corruption. No queue functionality provided, need a FIFO in the caProvider.
MK: Use existing queue-size config, affects both client and server.
RL: This will be work, needs tests to prove it’s working correctly.
MK: Problem probably exists for Java too, will examine.
pvAccessCPP from gitgub.com/mrkraimer fixes several issues. (factories)
Michael also working on solution.
consider separate registries for client and server.
MD: Semantics poorly defined
MK: Separate registries for server and client channel providers, good idea.
MD: Not started work yet, just need to know what names to use to replace the existing “getChannelProviderRegistry”. May affect all existing client code, want to avoid breaking current code. Want to implement a compatibility version, will try server first, then client if no server.
MK: If MD can work on this in the next few weeks I want to test this. Then after that I will work on the #63 issue (caProvider).
MD: Override and final, trying to figure out what’s going on. Lockable interface? Think I’ve just worked that out. Cleanup, conditional alignment code for padding removed, not needed. New class ChannelBaseRequester with one method channelDisconnect() to notify clients. Don’t install headers that didn’t need installing, shouldn’t be needed. New interface for starting servers with configuration. Cleaned up internal reference loop with CA servers, so they can now be cleaned up properly. Related issue, in IOC there is no need to start the server, happens through initHooks. Implements iocPause by stopping the server. New method to get actual server configuration information, useful for testing.
RL: Is there a way to *not* start the pvaServer?
MD: Not yet.
RL: There should be a way to suppress the automatic startup of the PVA server. Env var?
AJ: Could do the same for RSRV.
SV: Environment variable would be the best way.
MD: You can set the environment variable for the provider list to empty.
AI on RL/AJ: Create an issue to discuss, dbServer API to control starting of servers etc.
MD: Channel Provider ownership: Create…() functions should return unique pointers, so caller must clean them up to prevent a leak (except it isn’t). Wrapped/nested reference counters… Would like someone else try to understand this too. Think I have a solution, will update header comments to document semantics of this.
Asynchronous record support. issue #12 in pvDatabaseJava.
MK: Waiting for comments on my document posted to github & pvData-devel mailing list.
RL: This was the issue that Benjamin had questions about. Will try to get some feedback. Would prefer that asynchronous support be the initial version, sync can be implemented on async, the reverse is much harder and messier.
MK: May be a topic for a weekly hangout, not essential for EPICS 7.
RL: Mailing list discussion, solution agreed, default to [block=false] (pvaSrv already works properly).
MK: No implementation. For Java MRK can do now. For C++ waiting for other pvAccessCPP changes, will do then.
AI on MK: Implement this for Java; continue with C++ once the other changes have settled.
MK: Main use case was sub-array.
AJ: Protocol has offset & length.
MD: No client code uses this.
MK: Was using pvget & pvput to test.
RL: My original idea was that pvaSrv/QSRV would convert pvRequest configurations into server-side filters for interfacing with the IOC.
MD: Would like to see someone who wants this.
MK: This is not a priority for EPICS 7.
RL: Avoid adding complexity when nobody is asking for it.
Agreed to delay this development until someone asks for it.
MD: When someone asks it, you can shout at me.
RL: Issue should be on the command-line tool pvget, which doesn’t support the existing subarray feature in pvAcces protocol.
RL: Have experimented with splitting Base into separate modules, wanting to allow bug-fixes to be merged up. Can’t really use the split because it only handles paths under the split directories, have to do this by keeping the full history of Base in each module and remove different parts from each module. Disadvantage is larger history data. Now need to name the sub-modules. At the Feb meeting we gave the names core, ioc/database and ca. Are these right, and where does RSRV live?
AJ: RSRV currently has to live in the database; until we can move dbCa out we have to build the ca client (and install rsrv.h) before the database. Changes to the dbServer API should remove the rsrv.h requirement, I want to add startup, pause and stop methods to it.
RL: Should the separated modules be branches in the same repo, or separate repo’s?
AJ: Ok with keeping them in the same repo.
RL: Version numbers for the modules? Start core and database with the current version; start CA with the current protocol tag.
AJ: What about release branches, as used with V4?
RL+SV: Start using them.
Discussion about bug tracking…
AJ: Suggest we create new EPICS 7 projects on Launchpad and public bugs can be moved to the appropriate sub-modules.
SV+SH: Suggest try to using just one of (github or launchpad), mostly for bug-tracking.
RL: Earlier discussion said we can’t move bugs off github; moving from github seems the wrong way; we decided to wait for now.
RL: V4 modules included in EPICS 7: pvData, pvAccess, nt, pvaClient, pvaSrv/QSRV.
SV: Why not include pvDatabase too? Omitting it makes building pvaPy and AreaDetector more tricky.
AJ: Sounds likes it needs to be in.
RL: Should pvaPy be in or out?
SV: OK with it being out.
MK: Which parts of pvData would move to libCom?
AJ: Utility classes/functions, Locking class (replace with epicsGuard?), etc.
RL: Base modules may have tests with additional module requirements (e.g. p4p) as long as the regular build still works without them.
AJ: Should the tests be included in Base? Build is much simpler if the tests stay in external modules (including the tests in Base would result in a chicken-and-egg build problem).
RL: What to bundle for release: EPICS 7 Base, EPICS 7 Python, EPICS 7 Java (most users will get binaries from Maven Central).
Present: SH, SV, KV, MK, AJ, RL, AD, MD(alesio), GS, MD, BD
AJ: rsrv-registrar branch allows IOC to be built & run without CA server (local dbCa channels still work).
AJ: exampleCPP modules should become makeBaseApp templates
RL: Will get it to build first, then do that conversion.
MK: Should there be simpler examples for training?
RL: Didn’t need one for the training.
GS: Might be worth looking at.
AJ: Suggestion to consider: Does it make sense to combine V4 modules for building, e.g. pvData+nt, pvAccess + pvaClient?
RL+MD: Hadn’t considered this…
SV: Provide Make variable to list the individual V4 libraries definitely worthwhile.
RL: Consider combining libraries as another step later on.
AJ: Status of QSRV, pva2pva for EPICS 7 merge?
MD: QSRV should be ready, pva links are not on the list (not planning on it)
BD: Funding that was supposed to cover that has not come through. Prototype gateway works and is robust, but is still a prototype.
RL: CA Gateway has never been in Base, reasonable for pva2pva to remain as a separate module (independent release).
MD: Currently there are 3 parts in the same repo, can be split out. Test utilities are separate subdirectory, then gateway + server + links.
RL: Server should be split out and included in EPICS 7 bundle (QSRV). With this we can drop pvaSrv, which works with Base-3.14 so may want a separately released module. I see no feature for which pvaSrv would be preferable to QSRV (but that is 3.16 only).
MD: Initial work on qsrv and pva2pva had problems with pvaPy; some were related to pvaClient, but caused a week of bug-hunting in testing tools. Didn’t have much time to spend fixing this, or funding to work much further. … Implementation of p4p doesn’t use boost::python, which has been troublesome in the past. The p4p implementation has let me push pvAccess queuing and flow-control harder, so an excellent tool for me.
AJ: Should this be a public API? We now have 2 Python APIs.
MD: The p4p module has its own tests, which are part of its own code.
SV: Addressing scalability issues: AJ forwarded me an email with use cases that were causing concerns. Addressed many problems last summer, numpy worked well for us, have had no complaints since then.
SV: For demo: I wrote a C++ client using the pvaClient API, monitors one channel and counts updates (and misses), for a baseline of what’s possible. Michael gave a simple database spam.db that counts as fast as possible (starts IOC). Pure C++ client can receive messages at 100KHz. Wrote python equivalent using pvaPy, calculates how many messages missed, to compare with pure C++; this achieves 90-99KHz, not much worse than C++. A longer test 1Hr run 3 times the difference was only 3-5% slower.
SV: Next Michael suggested monitoring 2 channels; total throughput is slightly better than for single channel. Next tried 10 channels, some channels get lower rate up updates, but total throughput stays about the same, 100KHz total.
SV: The other use-case from Michael was scalability, scale.db, which updates large numbers of counters at 1Hz. Testing using 10,000 channels. Wrote similar C++ and Python client programs, which examine the monitor values to work out how many are missed. No problems monitoring 10,000 channels.
MD: How many threads are running, please run pstree or top in thread mode.
SV: (done, shows some more but not 10,000). With the changes last summer now I don’t create threads for each channel by default. Now running with 50,000 channels (demo) – went up to 75,000 channels; at 80,000 pvaSrv has problems, can’t connect all. I connect channels in bunches of 1000, with a 1 second delay between each bunch.
KV: We compared pvepics with pvaPy, pyepics connected 1000 PVs in <100ms.
SV: Demo shows can connect 50,000 channels without any problems. Going down to 1000 channels, connection is fast (sub-second).
MD: You should never be able to overwhelm pvaSrv with too many connections at once.
SV: Results – 10,000 channels never missed; 50,000 channels missed one; 75,000 channels missed up to 3.
MD: Was anything changed recently?
SV: Nothing modified since last summer, in the 4.6.0 release.
SV: Final demo, using the pvaServer demo used at the training in Japan; generating updates at over 200KHz. With python client and server we get 20% more updates than with the IOC server, 130KHz, so better than using pvaSrv. Performance doesn’t seem to be a problem.
MD: The other part of my test plan was handling disconnect and reconnecting.
SV: (writes simple python code live, various checks...)
MD: In order to start monitor the channel has to be connected?
GS: That might be a problem. When starting clients not all channels may be available.
MK: pvaClient can give you a callback when connection happens, should use this.
SV: Ok, need to talk and add this. Please let me know of any problems in the future.
AJ: Anything more on the Access Rights issue? API change
MD: Plus protocol modifications.
AJ: Needs doing, nobody to work on it right now.
BD: Needs to be addressed, not immediate need, might be on ESS’ list. Other things have higher priority – alarm service is higher.
SH: BEAST is available which may provide that.
BD: Does it have multiple independent views of the available alarms?
SH: Probably tied at the moment, would need multiple setups. Can us JMS to store the current state.
BD: But the results are not available over pvAccess yet.
SH: Kay has it all in a relational DB, could add a PVA server on top.
GS: Slightly different requirement, want to get alarm statistics and history
SH: Would be a different service, not in scope.
BD: ESS work should include defining the requirements and API for authorization (we have stubs for authentication in V4 already). First step should be to implement as much as we have in CA. If the authZ change is big it’s not in scope.
MD: We’ve reached the point where we need to ensure the protocol mechanisms are present to not break when we upgrade things.
AJ: Point about using minor version numbers to negotiate capabilities across versions...
MD: Demo of p4p: Easier to build since it doesn’t need boost::python, just like other EPICS modules; uses pvData, pvAccess, needs numpy. Friendly with multiple python versions. Has unit tests.
SV: Have number of tests, using nose; didn’t have a pvaPy server until recently, now I can automate that. Can use system’s Boost, although we build our own at APS. Have scripts to build that, Andrew will be looking at the build issues for future use. Our configure scripts figure out the flags etc.
MD: Documentation, getting started, shows API, structure access, unwrapping values when dealing with simple types (scalarValue, scalarArray). Unpacking NTTable as iterable object, imagine converting into a Panda table, nice for interactive usage. Various helpers to translate into other python-friendly values. For blocking API the context wraps default provider name; API identical to cothread. By default starts on a random port, to avoid clashes with other servers, configurable and queryable. RPC Server, decorators for proxy objects and name expansion. Internally this is entirely callback-based. Blocking parts are entirely in Python, allows for use with pyQt, coroutines etc.
Present: AJ, RL, KS, AD, MDalesio, GS, EB, BD, MG, SH, SV, KV, MK, MDavidsaver, GC?
AJ: Gave overview of Core group discussions.
EB: Had issues with Eclipse framework; looked into advantages & disadvantages of this, looking at other options.
KS: Many features from Eclipse are now part of JDK, may not need the full Eclipse platform any more (after 10+ years).
EB: Can’t make major decisions with only a subset of community present (Diamond & Claudio).
KS: Still just exploring the possibilities.
SH: When would you make a decision?
EB: By our next Codathon.
KK: Display builder, editor and pvTree can already be stand-alone. pyDev would work.
BD: How to handle pop-up menus to link to other programs?
KK: Stand-alone products but want to allow packaging them together. Various Eclipse features have equivalents that could be used for integration.
EB: Discussion was how to keep the things we like and then fix the build.
KS: Java has multiple choices for integration and communication between apps; we have to keep the integration, and try to keep configuration files as much as possible.
KS: Merge NTTypes and VTypes? No; different purposes, keep them separate.
SV: What is the V?
KS: Ownership of Java modules – we will take leadership, for all V4 modules plus CAJ/JCA.
AJ: RMI too (JCA)?
KS: Would want help…
AJ: Core group don’t know the JNI API, but would help.
RL: The JNI version has been deprecated for some time. Various sites are probably still using it because there were issues with the CAJ version, but recently those seem to have been resolved.
KK: Recent issue on tech-talk with Null PV name report from the Gateway from CAJ clients
SH: Don’t know precisely where this is coming from.
MD: Search messages without the proper padding, so were showing up as unaligned.
RL: I will be moving the code to Github, so that’s where we should handle the issues.
AI on RL: Email tech-talk to ask who is still using the JCA (RMI) version, will there be screams about abandoning the C+RMI implementation? (Done. No screams within 96 hrs).
MD: Watching KS working on MASAR, type-mismatching on what he was getting vs expecting; how to handle this? Ugly and long code. This was why I added the getAs & putFrom methods to C++. Suggest this should happen in Java, bug Gabriele suggested there’s a different better approach. Point being we’re ending up with brittle client code that can’t handle mismatches.
MK: There’s the convert utility.
KS: Very little used, it’s not intuitive as a Java API.
MD: A difference between 1 line of code and 10.
GC: Problems of type conversion were solved for pvManager and DiiRT, … For performant code have to go back to array of primitives. … With those implementations the JVM was able to optimize things; take those classes and import them into V4 modules. In org.diirt.util – stop-gap solutions for common Java problems that help with common operations; thin classes that make our lives easy.
KS: Specific classes we can start with.
GC: Things will change again in Java10, value classes can be substantiated in arrays, so these will have to be revisited in a few years.
AJ: Are we OK with adjusting the public APIs to make them more native-like?
GC: Have common internal APIs for protocol-level code, so a protocol expert can work on both, but the user-facing APIs can be optimized for the 2 languages.
MK: Changing the pvData APIs will affect pvAccess won’t it?
MD: We see this as a strict addition, they won’t change the pvAccess usage. We want to optimize these APIs for the use-cases. Fundamental difference between how the run-times behave for certain kinds of code.
GC: Agreed, very different implementation details. Sympathise with trying to keep the two stacks similar.
AJ: OK, we seem to have a way forward.
MK: Should we raise the put vs. put-callback issue for the CA provider?
KK: Using the CA transport we have both.
MK: ESS with no CA – but then pvaSrv is OK to handle this.
KS: Observations of using V4, see https://docs.google.com/document/d/1Lyufkp3OunOMHEJlY5pf7DVf6cFmqk7ZatN6c09GBY8/edit#
KS: Looking for an API along the lines of the Java Collections library, would be more intuitive for Java developers.
MK: The pvData library does have CreateBuilder methods, should really simplify some of this code.
KS: Documentation suggests using the more complex APIs; are we deprecating APIs?
MK: Nobody is really working on these; MD has done stuff for the C++ implementation to make things easier, which haven’t been done the Java.
KS: As MD and GC have said they have utils already, we should look at those.
MK: Matej added fieldBuilder stuff which made things much easier; look at the Application Developers’ Guide, which covers both APIs. (link here…)
KS: Also good to add notes in the older APIs pointing to the new better ones.
AJ: Definitely, please update the JavaDocs as you see fit. Also adjust APIs as GC and MD suggest.
RL: Our doc’s should be structured such that the dev guide guides you, the reference is in the javadoc.
AJ: Probably nothing specific to discuss at this point, just letting everyone know that these need working on.
SH: (see document, which will be shared publicly soon, including to tech-talk; there will also be an official announcement at ICALEPCS).
RL: Kazuro Furukawa is trying to encourage collaboration in Asia and there are still many labs using EPICS, but without much publicity or sharing. EPICS is seen as “the system the old guys use”.
LP, GitHub, or even GitLab at a lab?
AJ: Not convinced we need to change anything at this point, given that future directions of GitHub and Launchpad are not obvious.
RL: Agreed, don’t want to spend time converting old bug reports again.
SH: AJ mentioned setting up an EPICS 7 project on LP.
AJ: Probably best to set up a separate release series for 7 under the epics-base project.
(Discussions about the website).
Formal agenda completed, tomorrow will be for ad-hoc discussions.
RL: Talked to Murali, his changes should all be in the Hg repo. Will check Michael’s conversion has them and push them (without MD’s additions) to the new GitHub repo, then ask MD to submit a pull request for his extras.
MD: Mostly concerned about external code using our APIs, our object ownership rules are convoluted and need fixing, but this would break that code. Requester’s should hold a strong reference to things they are given, but they don’t all do that. Can’t change to sane behaviour without breaking some existing code.
AJ: Can you document this, describe what needs to change and what the ownership rules and policy are supposed to be. We should aim to make this change in V7, but discuss it with our users before finally merging the necessary changes.
BD: Need to let our users know in advance. Now’s the time to change it before we get 100 people using it.
MD: Yes, need to write out the rules for my own sanity.
AJ: Heinz, where are we with RTEMS 4.12?
HJ: Have tested on PowerPC beatnik; mostly working on ARM; can’t run on Intel yet because of an exception problem (throwing std::runtime on PC BSP fails, https://devel.rtems.org/ticket/2830).
MD: Are you testing against older RTEMS versions?
AJ: I have tested the build against 4.10.2 and can build against 4.9.2, but not HJ’s latest version.
AI on AJ: Test-build HJ’s latest version, look for remaining issues.