driver_oncore fails to fire up (rev 6227 trouble)

[Håkan Johansson-5]

Hi,

revision 6227 introduced a construct

  if (event == event_configure && event == event_reactivate) {

into driver_oncore.c (line ~400).  The oncore does not start any longer.
Please revert to the old behaviour.

(Regarding the comment in the code above that line.  The devices do keep
settings, i.e. after firing it up, if I kill gpsd, it will continue to
spew messages indefinately.  I suppose, if we would start to shut it down
on some event_deactive, then its another story.)

I also saw that drivers.c has a similar construct.

Cheers,
Håkan
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Håkan Johansson <f96hajo@...>:
> revision 6227 introduced a construct
>
>  if (event == event_configure && event == event_reactivate) {
>
> into driver_oncore.c (line ~400).  The oncore does not start any longer.  
> Please revert to the old behaviour.

That's not trivial. What you're seeing is the result of a major
rewrite of the driver API, not a three-line patch somewhere. Also, I
don't have an Oncore device to test, so I will need your aacxtive help
in fixing this..

What that conditional is intended to do is enable the sending of initializatrion
strings when two particular events fire.  I have attempted to change that
conditional to something that looks more nearly correct, but you will have
to review and test it.  I'm not sure I have chosen the right events
to send those strings with correct timing.

For a detasiled description of the events and when they are sent, see
www/writing-a-driver.xml.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Håkan Johansson-5]

from looking at other drivers, it seems it should be something like

if (event == event_identified || event == event_reactivate) {

or just

if (event == event_identified) {

However, I never get a event_identified notification, and grepping in the
code does not show me any place where that is generated.  Is it missing,
or me?

// Håkan


On Wed, 4 Nov 2009, Eric S. Raymond wrote:

> Håkan Johansson <f96hajo@...>:
>> revision 6227 introduced a construct
>>
>>  if (event == event_configure && event == event_reactivate) {
>>
>> into driver_oncore.c (line ~400).  The oncore does not start any longer.
>> Please revert to the old behaviour.
>
> That's not trivial. What you're seeing is the result of a major
> rewrite of the driver API, not a three-line patch somewhere. Also, I
> don't have an Oncore device to test, so I will need your aacxtive help
> in fixing this..
>
> What that conditional is intended to do is enable the sending of initializatrion
> strings when two particular events fire.  I have attempted to change that
> conditional to something that looks more nearly correct, but you will have
> to review and test it.  I'm not sure I have chosen the right events
> to send those strings with correct timing.
>
> For a detasiled description of the events and when they are sent, see
> www/writing-a-driver.xml.
> --
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> _______________________________________________
> Gpsd-dev mailing list
> Gpsd-dev@...
> https://lists.berlios.de/mailman/listinfo/gpsd-dev
>

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Håkan Johansson <f96hajo@...>:
> from looking at other drivers, it seems it should be something like
>
> if (event == event_identified || event == event_reactivate) {

That's what I changed it to.

> or just
>
> if (event == event_identified) {

Right. It's sometimmes unclear what each individual device needs;
initializing of identification only is usually sufficient, but reinitializing
on a reactivate is extra-safe.

> However, I never get a event_identified notification, and grepping in the
> code does not show me any place where that is generated.  Is it missing,  
> or me?

It was.  I'll run svn blame and figure out why, but it's back in trunk.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Håkan Johansson-5]

>> However, I never get a event_identified notification, and grepping in the
>> code does not show me any place where that is generated.  Is it missing,
>> or me?
>
> It was.  I'll run svn blame and figure out why, but it's back in trunk.

I still do not get event_identified and cannot find its generation.  Is it
libgpsd_core.c:536 that should be changed?

Problem?: driver_tsip.c and driver_ubx.c have the notorious constructs
with  if (event == event_identified && event == event_reactivate) {

and drivers.c has a
if (event == event_configure && event == event_reactivate)

Cheers,
Håkan
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Håkan Johansson <f96hajo@...>:

>
>>> However, I never get a event_identified notification, and grepping in the
>>> code does not show me any place where that is generated.  Is it missing,
>>> or me?
>>
>> It was.  I'll run svn blame and figure out why, but it's back in trunk.
>
> I still do not get event_identified and cannot find its generation.  Is
> it libgpsd_core.c:536 that should be changed?
>
> Problem?: driver_tsip.c and driver_ubx.c have the notorious constructs  
> with  if (event == event_identified && event == event_reactivate) {
>
> and drivers.c has a
> if (event == event_configure && event == event_reactivate)

Fixed.  You have demonstrated two things:

1. I need to get more sleep or something.  That was a careless error of
a sort I should not have made, and normally don't.

2. My test framework isn't good enough to pick up errors in the event-related
coding.  Because the regression tests use checkfiies rather than live
GPSes, they can't catch stuff like this.  Unfortunately, I can't think
of a practical way to address that problem.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev