RE: Dynamic Loading and Unloading of EPICS Device Support and Record.

["Dalesio, Leo" <dalesio@bnl.gov>]

Title: RE: Dynamic Loading and Unloading of EPICS Device Support and Record.

I'm not so sure that adding records is a really big job. I would say it is non-trivial.
It would be interesting to test on a single record type - with softDevSupport.
Then try to port a device support into the environment.
Then in a record that is linked to other records.
After that - you understand what it takes to do it to the other devices and records.

I agree with Benjamin - the use case is 24/7 operation forever.
I agree with Eric - it makes things more complicated.
I agree with Andrew - rebooting is easier. However, you need to assure that hardware does not go into some weird state when you do this. Does you hardware and software support bumpless reboot?
I agree with Marty - V4 database already does this. OTOH, it does not have the operational hours to say that it is ready for prime time. But it could be used in this case as a good alpha test site.

Bob

-----Original Message-----
From: core-talk-bounces@aps.anl.gov on behalf of Marty Kraimer
Sent: Wed 9/8/2010 3:06 PM
To: Core-Talk
Subject: Re: Dynamic Loading and Unloading of EPICS Device Support and Record.

  On 09/08/2010 01:44 PM, Dalesio, Leo wrote:
>
> Marty should chime in here too.
> There were two large issues with dynamically adding records -
> 1) recomputing the lock sets - which was handled when modifying
> database links was implemented.
> 2) I believe was the record initialization and device support
> initialization issues. To be clear on this, it would be best to read
> through the record type and instance initialization, the device type
> and device instance initialization, and the driver initialization.
> Most likely, existing device and driver support would need to be
> reworked. For a while, I would just not write an initialization
> routine and take care of that in the read or write. That way I knew it
> could be done at any time.
>
> I would not delete records. This really opens a can of worms. It would
> be more straight forward to disable them. Create a new alarm severity
> - disabled. Then the action to take on disabled can be configured. No
> channel access to it through access security rules for instance.
> The deletion is more complex, as references to that record within an
> IOC, resolve to the memory location to improve the performance. A
> record does not know everyone that refers to it. To further complicate
> things, there are also state programs that would have to deal with
> records going away. Currently they support channel access disconnects
> - so perhaps this is not as difficult as I think.
>
> In any case - start with being able to add them dynamically. If that
> goes well and you're feeling brave - then go for delete second.
>
>
>
> -
>
Let me explain briefly how the javaIOC handles dynamic creation and
deletion of database records.

Rather than lock sets each javaIOC record is locked. To handle links
between records it is possible to lock one additional record besides the
currently locked record. The implementation prevents deadlocks.

In addition any code that accesses a record must register itself by
supplying a callback method named "detach".

Each record instance has a RecordProcess created for it. RecordProcess
calls the top level Support which must exist. Each field can optionally
also have a Support.
RecordProccess and Support implement the following methods: initialize,
start,process, stop, and uninitialize. When initialize is called the
support can create anything it requires for processing but can not
access anything outside the record. Start can connect to things outside
the record, e.g. hardware, other records, channel access, etc. Process
is called when a record is processed. Stop undoes start. Uninitialize
undoes initialize.


There are two databases involved with records that can be processed:
master, and beingInstalled.

The following is done to delete a record: The record is removed from the
master database. The detach method of all registered code is called.
After detach is called the code must no longer access the record. Then
RecordProcess.stop() is called. This results in all Support.stop()
methods being called, Then RecordProcess.uninitialize is called which
again results in all the Support.uninitialize methods being called.
After this the record is gone.

To add a record, actually a set of records, the following is done: The
records are added to the beingInstalled database. For each record the
following is done: Look for all fields that have a request to replace
the current PVField implementation. Ceates a RecordProcess for the the
record and create the Support for all fields that have support. Then
call RecordProcess.initialize and then RecordProcess.start,. If anything
fails during this install quits. If all succeed then the beingInstalled
records are moved to the master database. It is somewhat more
complicated than this but not much.

The really big problems with the v3 IOC are: 1) lock sets, which span
records, and 2) There is no equivalent in record support or device
support to stop and initialize, and 3) There is no equivalent to detach.

For lock sets  I think it means the entire database must be locked while
a record is added or deleted so that lock sets can be recomputed. There
is already a global lock for the database which gets locked if a new
access security file is loaded into a running IOC. I think I am
remembering this correctly. But it does mean the entire database must be
locked which makes everything freeze.

To support stop and unintialize all record/device code for any record to
be added or deleted must be upgraded. In addition any code that accesses
record instances must register and provide a detach method.

Sounds like a really big job.

As Bob says you could decide not to support record deletion. That
removes the need to support stop and uninitialize and detach. That
simplifies what must be done. But lock sets still appear to be a problem.

I would still  go with the idea of a beingInstalled database. One thing
to remember, however, is that code that accesses other records (dbliink
calink) must look in both master and beingInstalled when looking for
local records.