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

[Chris Johns via Core-talk <core-talk at aps.anl.gov>]

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