EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <2008>  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <2008>  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: PV Gateway
From: Dirk Zimoch <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: [email protected]
Date: Fri, 22 Aug 2008 09:55:06 +0200
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
Replies:
Re: PV Gateway Andrew Johnson
References:
PV Gateway David Dudley
Re: PV Gateway David Dudley
Re: PV Gateway Dirk Zimoch
Re: PV Gateway Andrew Johnson
Navigate by Date:
Prev: PV Gateway and IOC running Epics 3.12 Angelic Ebbers
Next: RE: Motor home status Pearson, MR (Matthew)
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <2008>  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: PV Gateway Gasper Jansa
Next: Re: PV Gateway Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <2008>  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·