Re: PV Gateway

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi all,

Andrew is right, I have added the "hack" to the gateway Makefile to get the 
headers from EPICS_BASE. But as David has seen, it does not work if 
INSTALL_LOCATION of base has been modified. We have the same situation here at 
PSI. Thus, I had to install the header.

At the moment, there is no proper way to get the header information 
automatically. And I think we need some way. One should probably reconsider 
which information is really "private" and which not. For example the event mask 
of the client is not really a secret. Why should the server not find out about 
it? But an official API is missing. Thus, the only way is to look into the 
"private" parts of cas.

It is in particular this code (from gateVc.cc) which requires access to casCtx.h:

caStatus gateVcData::read(const casCtx& ctx, gdd& dd)
{
	...
	/* This is to obtain mask from client */
	if(ctx.getMsg()->m_cmmd == CA_PROTO_EVENT_ADD){
		struct mon_info *pMonInfo = (struct mon_info *) ctx.getData();
	//If build with R3.14.9 next two lines must be switched	
    // 	ca_uint16_t caProtoMask = AlignedWireRef < epicsUInt16 >(pMonInfo->m_mask);
		ca_uint16_t caProtoMask = epicsNTOH16 (pMonInfo->m_mask);

		if (caProtoMask & DBE_LOG) {
			client_mask = DBE_LOG;
		}
	}
	...
}

It would be nice to have a getEventMask() method instead. Should I add this to 
Mantis?

Also note that the code needs modification for R3.14.9 because of an other 
"private" thing in base: Byte order handling. (Well, it's not private in the 
sense that the headers are not available but in the sense that functions have 
disappeared and have been replaced with other functions. I have to assume it 
they where meant to be private because using them break the code when upgrading 
EPICS base. It would also be nice to have an "official" byte order API in libCom 
(for C, not only C++) because not only channel access needs it. Also some 
drivers may be interested in the byte order and need to convert. Should I add 
this to Mantis?

BTW: I have requested earlier that byte order is either detected automatically 
(from endian.h where it exists) or can be configured in the 
CONFIG_<arch>_something file. Having to hack code like the following (found in 
base-3.14.9/include/os/Linux/osdWireFormat.h) is no good style:

#if defined (_M_IX86) || defined (_X86_) || defined (__i386__) || defined 
(_X86_64_) || defined (_M_AMD64)
#	define EPICS_LITTLE_ENDIAN
#elif ( defined (__ALPHA) || defined (__alpha) )
#	define EPICS_LITTLE_ENDIAN
#elif defined (__arm__)
#   define EPICS_LITTLE_ENDIAN
#else
#	define EPICS_BIG_ENDIAN
#endif

Will this be fixed in 3.14.10? Should I add this to Mantis?

Best regards,
Dirk

Andrew Johnson wrote:
> On Thursday 21 August 2008 02:32:45 Dirk Zimoch wrote:
> > I think, the two headers were supposed to be "private" to cas. But since
> > the gateway needs them the base Makefile should be modified to install
> > them. That's what I did and it works fine. However I didn't try 3.14.9. but
> > run with 3.13.8.2.
>
> The latest version of the gateway in CVS has the following added to the 
> gateway/Makefile which completely avoids the need to install those files:
>
> # need access to casCtx.h
> USR_INCLUDES += -I$(EPICS_BASE)/src/cas/generic
>
> This method also makes it a little more obvious that the gateway code is using 
> private APIs inside CAS that could change as the CAS implementation changes.
>
> > I have added a bug report to Mantis
> > (http://www.aps.anl.gov/epics/mantis/main_page.php).
> >
> > Someone could add that information to the gateway documentation. :-)
>
> For maintainability reasons I much prefer that we modify CAS to make the 
> necessary API routines or their equivalents available through the official 
> headers.  Installing or using private headers makes the innards of the CAS 
> implementation visible to applications, which means that future changes to 
> the implementation of CAS can break the external code that has started using 
> these private APIs.  I'm sure Jeff will agree with me on this point.
>
> Unfortunately this issue has surfaced too late for any changes to CAS to be 
> included in R3.14.10, but I hope that we'll be able to work something out 
> soon afterwards and provide a patch file for CAS to be used when building the 
> gateway until the next Base release.
>
> Dirk, these headers were added by your patch to the gateway that Janet applied 
> last year, can you explain to Jeff what functionality you need from CAS.
>
> - Andrew

--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182