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

[Andrew Johnson via Core-talk <core-talk at aps.anl.gov>]

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.