Code review comment for lp:~epics-core/epics-base/link-support-2

Revision history for this message
mdavidsaver (mdavidsaver) wrote :

> ... link will be copying metadata which will never be used ...

Oh, Andrew I thought you knew me better than this :) There is no reason to extra copying. Double buffering and/or a bit mask (like dbGet *options) can avoid this. I don't see that any significant overhead need be added.

To modify my previous:

> long (*getValue)(struct link *plink, short dbrType, void *pbuffer,
> long *pnRequest, const dbr_ctrl_double **meta);

where:

> const dbr_ctrl_double *pmeta = NULL;
> ...->getValue(... , &pmeta);

The pointer stored in 'pmeta' would remain stable until the subsequent call to getValue.

Do you have any thoughts about imposing an ordering requirement? (dbGetLink first then metadata calls)

> ... When writing a record type or device support which does the get itself
> ... you can set TSEL=-2 ...

> Your discussion about TSEL is for the case where you want to copy the timestamp from the same place as the INP link, without having to set up a second link — is this correct?

Yes. Although I'm focused on CA-like links, not the HW links that I think you're considering. The TSE=-2 hack is sufficient for HW links, but isn't relevant otherwise. It might be better if you think about this in the context of calcRecord, which doesn't (and shouldn't) know about the difference between DB/CA/... links.

To rephrase my previous example:

> record(calc, "xxxx") {
> field(INPA, {ca:{pv:"src:pv",proc:"CP"})
> ...
> field(TSEL, "xxxx.INPA")
> }

My requirement is to ensure that the result will have the same timestamp as the input update it derives from.

« Back to merge proposal