Experimental Physics and
Industrial Control System

"Rees, NP (Nick)" <[email protected]> · Wed, 24 Sep 2008 09:44:19 +0100

Eric,

As an example, we have an interpose interface that has the following
declaration in it:

static asynOctet octet = {
    writeIt,writeRaw,readIt,readRaw,flushIt,
    registerInterruptUser, cancelInterruptUser,
    setInputEos,getInputEos,setOutputEos,getOutputEos
};

Where the initising elements are static functions. The purpose of the
interpose interface is to sit between and asynIPPort and
asynInterposeEos processing to add and strip some network protocol
headers. The payload is traditional ASCII text with terminators. I
thought this sort of declaration was fairly standard, but clearly it has
to change or have a conditional compilation statement in it.

The protocol headers are added on in the writeIt routine. The writeRaw
function is a trivial pass through function that essentially just calls
the underlying writeRaw routine. 

The readRaw routine keeps reading until it has a full transmission so it
can then strip the headers off. The readIt routine does a little bit of
work because there are some occasional cases when the terminators are
non-standard.

Are you suggesting:
1. Don't ever do structure initialisation of asyn**** interface types.
Instead either start with a null interface, or one copied from another
underlying interface of the same type, and only assign the methods you
want to add or change. If you only support C99, you can do
initialisation by member assignment.
2. In this case, interpose the protocol headers at the asynOctet layer,
and assign, not initialise new read and write routines. I am not certain
where the fiddling with non-standard terminators should go - possibly in
the same routine or as an interpose in asynInterposeEos.

Whatever we do, it is not a trivial change.

The code is in pmacAsynIPPortSrc in the pmac code available from the
GMCA CAT website http://www.gmca.aps.anl.gov/TPMAC2/.

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713 

> -----Original Message-----
> From: Eric Norum [mailto:[email protected]] 
> Sent: 23 September 2008 18:24
> To: Rees, NP (Nick)
> Cc: Andrew Johnson; Mark Rivers
> Subject: Re: ASYN R4.10 Release
> 
> I'm sorry that you weren't included on the discussion list for this.
> 
> As far as I know there are no low-level drivers that ever 
> implemented  
> anything except readRaw and writeRaw so all cooked/raw selection was  
> being done only by the interposeEos level anyhow.
> 
>   I expect that you won't need to add any conditional compilation --  
> any changes you need to make to get things working with the latest  
> version of ASYN will apply and work just as well with the previous  
> versions too.
> 
> 
> On Sep 23, 2008, at 11:52 AM, Rees, NP (Nick) wrote:
> 
> > Eric,
> >
> > Why have the writeRaw and readRaw interfaces been removed? This  
> > seems to
> > break the rule that we should always try and retain backwards  
> > compatible
> > interfaces. I am already getting complaints that asynOctet 
> devices we
> > support have broken. Doing this without a cast iron justification  
> > seems
> > rather strange to me. I now have to maintain code that will compile
> > against multiple versions of asyn and so I need a number of horrible
> > ifdef's.
> >
> > Cheers,
> >
> > Nick Rees
> > Principal Software Engineer           Phone: +44 (0)1235-778430
> > Diamond Light Source                  Fax:   +44 (0)1235-446713
> >
> > <DIV><FONT size="1" color="gray">This e-mail and any 
> attachments may  
> > contain confidential, copyright and or privileged material, 
> and are  
> > for the use of the intended addressee only. If you are not the  
> > intended addressee or an authorised recipient of the addressee  
> > please notify us of receipt by returning the e-mail and do 
> not use,  
> > copy, retain, distribute or disclose the information in or 
> attached  
> > to the e-mail.
> > Any opinions expressed within this e-mail are those of the  
> > individual and not necessarily of Diamond Light Source Ltd.
> > Diamond Light Source Ltd. cannot guarantee that this e-mail or any  
> > attachments are free from viruses and we cannot accept 
> liability for  
> > any damage which you may sustain as a result of software viruses  
> > which may be transmitted in or with the message.
> > Diamond Light Source Limited (company no. 4375679). Registered in  
> > England and Wales with its registered office at Diamond House,  
> > Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11  
> > 0DE, United Kingdom
> > </FONT></DIV>
> 
> -- 
> Eric Norum <[email protected]>
> Advanced Photon Source
> Argonne National Laboratory
> (630) 252-4793
> 
> 
> 
<DIV><FONT size="1" color="gray">This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
</FONT></DIV> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System