Re: What is the next step for RTEMS and EPICS? Does a small (virtual) workshop make sense?

[Heinz Junkes via Core-talk <core-talk at aps.anl.gov>]

Hi Andrew & Chris & Gedare,

yes, we should definitely meet. I may not be able to be there on the very next Wednesday :-(
I am giving a class from 2pm to 5pm.

A lot has happened with RTEMS and EPICS recently. It's been so fast that I haven't kept up with it at all.
But we should use the momentum now and incorporate what we have achieved into the next release of EPICS.

I withdraw my PR (https://github.com/epics-base/epics-base/pull/295).

This week I have intensively tested Chris' PR (https://github.com/epics-base/epics-base/pull/375) 
on my hardware (MVME6100 and MVME3100). 
Vijay has made some improvements in the RTEMS kernel which have been included there. 
I have changed only a few small things in posix/rtems_config.c 
(e.g. 
-#define CONFIGURE_MICROSECONDS_PER_TICK 10000
+#define CONFIGURE_MICROSECONDS_PER_TICK 1000
)
which I will then submit collectively.

I already have the hardware in use with the usual modules:
asyn, autosave, busy, calc, devlib2, ip, ipac, recsync, seq-2.2.8, sscan

Everything compiled perfectly. We should please adopt Chris's PR in EPICS right now. 
This will we'll make a lot of progress.

I myself will try to integrate the ntpd as a time provider next week and try to create
documentation for RTEMS6/EPICS7 at the end of August for the Documentathlon. I would also
have to provide a test for CI?

I'm sure I've forgotten a few things. It all just happened so fast now. 
Thanks again to Chris, Vijay and Zainab. 

Heinz


> On 3. Aug 2023, at 21:51, Andrew Johnson via Core-talk <core-talk at aps.anl.gov> wrote:
> 
> Hi Chris & Gedare,
> 
> Would you be able to join our regular EPICS Core Developers meeting on MS Teams next Wednesday, August 9th at 9am US Central time, which is 14:00 UTC and I think 00:00 on August 10th for Chris? This will be the last meeting when Vijay and Zainab will be here at APS.
> 
> Other core-talk readers with a particular interest in RTEMS who are not regulars at the Core meeting would also be welcome, let me know if you want an invitation.
> 
> Thanks,
> 
> - Andrew
> 
> 
> On 8/2/23 9:42 PM, Chris Johns via Core-talk wrote:
>> Hi,
>> 
>> I would be happy to meet to discuss and plan the work we need to get done. As
>> Gedare says we need to find a suitable time to meet. I did do midnight last time
>> be it with a small puppy for company :)
>> 
>> Chris
>> 
>> On 20/7/2023 4:02 am, Gedare Bloom via Core-talk wrote:
>> 
>>> Hello Heinz,
>>> 
>>> On Fri, Jul 14, 2023 at 2:55 AM Heinz Junkes via Core-talk
>>> <core-talk at aps.anl.gov> wrote:
>>> 
>>>> Hallo,
>>>> 
>>>> right now I see a lot of RTEMS related EPICS activity. However, these activities do not seem
>>>> to be well synchronized (from my point of view) and also a bit jumbled.
>>>> Wouldn't we like to meet online one afternoon (Europe time) and discuss our common approach?
>>>> I am happy to organize this.
>>>> 
>>>> 
>>> That would be nice, although the time zones are quite challenging to
>>> cover (e.g., Europe, US, Hawaii, Australia). I have renewed interest
>>> and motivation in this direction and would be happy to help organize
>>> or participate.
>>> 
>>> We have recently started an #epics channel on the RTEMS discord. That
>>> is becoming a nice place for asynchronous and chat-oriented
>>> collaboration. I encourage any core developers interested in tracking
>>> RTEMS/EPICS activities to lurk :)
>>> https://devel.rtems.org/wiki/Developer/discord
>>> 
>>> 
>>>> Here my view:
>>>> 
>>>> Due to the request from some places (e.g. gemini) that the lack of NFSv4 support for RTEMS
>>>> precludes further use, I started looking into RTEMS a little more intensively.
>>>> 
>>>> It turned out that NFSv4 can only be realized with a (the) new network stack.
>>>> For this new network stack Chris Johns then developed a first NFSv4 version.
>>>> There is a PR (#295, https://github.com/hjunkes/epics-base/tree/rtems6) from
>>>> me to epics-base which has not yet been merged. In it I tried to keep the older versions
>>>> of Epics and also the old LEGACY_STACK running.
>>>> I did the developments primarily on an MVME6100. Here it quickly turned out that there is no support
>>>> for the Ethernet controller of the MVME6100 for the new stack. Then at an EPICS Codeathlon, Till Straumann
>>>> (Danke!) built a Nexus driver for it. This then allowed NFSv4 to be used to start st.cmd, etc..
>>>> 
>>>> Now I can also read the NVRAM settings, I am still in the process of reading the settings from U-Boot, etc.
>>>> 
>>>> I also wanted to use ntpd and other things like ptpd etc that are now available at RTEMS. But I haven't gotten around to it yet.
>>>> 
>>>> I had focused on the addon modules like asyn, motor, vmelib ... to get them running.
>>>> And then got stopped at autosave from problems with writes on NFSv4, described here:
>>>> https://devel.rtems.org/ticket/4723
>>>> 
>>>> And now of course I'm surprised that none of the NFSv4 claimers stumbled upon it.
>>>> And in parallel, developments are run based on the legacy stack even though it can never support NFSv4?
>>>> 
>>>> 
>>> I can't speak too much to these specific concerns at the moment.
>>> However, as luck(?) would have it, I have some unpaid days available
>>> to me yet this summer that I will be spending looking at the situation
>>> with RTEMS-libbsd and NFSv4.
>>> 
>>> 
>>>> That's why I would be very happy if we could talk about this in a concentrated way.
>>>> 
>>>> Danke, Heinz
>>>> 
> 
> -- 
> Complexity is free, it's Simplicity that takes work.