Re: [Hamlib-developer] target VFO proposal

[Stephane F. <f4...@fr...>]

On Sat, Nov 25, 2000, Frank Singleton wrote:
> 
> Looking at the latest API in rig.h,
> I have come to the conclusion we are missing
> something of great importance.
> 
> We have not provided a target VFO in the set/get cmd's
> 
  arg, you're darn right!

> For example...should we have this instead..
> 
> int rig_set_freq(RIG *rig, freq_t freq, vfo_t vfo);
> int rig_get_freq(RIG *rig, freq_t *freq, vfo_t *vfo);
                                                 ^-------- typo
> int rig_set_mode(RIG *rig, rmode_t mode, vfo_t vfo); /* select mode */
> int rig_get_mode(RIG *rig, rmode_t *mode,vfo_t vfo); /* get mode */
> 
I would prefer like this (which is the same of course):
 int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode); /* select mode */

maybe we can extend vfo_e with defines like RIG_VFO_CURR,etc.
and add some macros:

  #define rig_set_mode_c(rig,more)  rig_set_mode((rig),RIG_VFO_CURR,(mode))

> etc..
> 
> It seems silly, but without this, we dont have a solid
> "target VFO" for the existing commands.
> 
	hmmm, embarassing indeed.

> ie: set freq/mode could apply to any VFO, so which
> one gets the command.??   Is it really the towards
> the  VFO specified in previous last set_vfo() 
> 
	right now, this is the last vfo set, which is
	tricky with multithreaded apps, see below.

> So, some decisions.
> 
> 1. backend must "remember".  This could be part of private data
>    This is no big change to frontend API.
> 
[...]

> 2. Frontend API provide API with target VFO as
>    an argument shown above.
> 
> I think I prefer option (1), otherwise we may
> be adding VFO to everything.
> 
  Well, we might end up by havign to choose both, sigh.
  Unfortunately, it looks clear that we'll have to add the target VFO
  to everything in fact.  Just look at it, reentrancy-wise.
  
  Thread A				Thread B

/* not thread safe */

  rig_set_vfo(my_rig,MAIN_VFO);
  .					rig_set_vfo(my_rig,SUB_VFO);
  .					rig_set_freq(my_rig,MHz(435));
  .
  rig_set_freq(my_rig,MHz(28)); /* !!! */


/* thread safe, with some mutex around read/writes :^) */

  rig_set_freq(my_rig,MAIN_VFO,MHz(28));
  .					rig_set_freq(my_rig,SUB_VFO,MHZ(435));

  This CAN happen (and it will!). So we need to pass the vfo along
  to all the rig functions :(. That does not mean the death
  of the rig_set_vfo function though. However, on some rigs,
  the backend will have to explicitly change the vfo to update
  stuff (freq, etc.). At this point, the question is whether
  the backend should save and restore the current VFO when
  setting values.
  In that case, we would need also to implement option (1), just
  to reduce some set_vfo/get_vfo calls.

  I'm not sure if we have a good solution yet, but at least we have
  a good question to chew!!


any ideas? comments?

-- 
Stephane