gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] RFC: Patch tp prevent call to ntpd_link_* for driver_nmea


From: Gary E. Miller
Subject: Re: [gpsd-dev] RFC: Patch tp prevent call to ntpd_link_* for driver_nmea2000
Date: Wed, 30 May 2012 12:33:44 -0700

Yo Reinhard!

Wow, virtually impossible to tell your comments from mine.  In the
future please us standard quoting conventions....

Also, please keep gpsd-dev in the Cc list as others are following along.

To avoid further confusion I have to resort to top posting.

I think I see your problem now, in that the ioctl(TIOCMWAIT) fails on
the CAN device.  So what you need to do is come up with a patch that
stops the PPS thread from startnig but allows the ntpd shared memory
to be allocated.  Should be easy to do.

On Wed, 30 May 2012 10:36:35 +0200
"address@hidden" <address@hidden> wrote:

> Hallo, 
> 
>       -----Original-Nachricht----- 
> 
>       Von: "Gary E. Miller" <address@hidden> 
> 
>       An: "address@hidden" <address@hidden> 
> 
>       Cc: address@hidden, "Eric S. Raymond" <address@hidden> 
> 
>       Betreff: Re: [gpsd-dev] RFC: Patch tp prevent call to
> ntpd_link_* for driver_nmea2000 
> 
>       Datum: Wed, 30 May 2012 09:24:55 +0200 
> 
>       Yo Reinhard! 
> 
>       On Wed, 30 May 2012 09:13:54 +0200 
> 
>       "address@hidden" <address@hidden>
> wrote: 
> 
>       >  -- the usage of ntp with gpsd on the boat has no top
>       > priority 
> 
>       > for me, the support of more then one GPS device, the AIS
> transmitter, 
> 
>       > and other instruments come first. 
> 
>       Just because it does not interest does not give you
> permission to break 
> 
>       things for others. 
> 
>       Please tell me, what is broken by this patch, except that ntp
> support is not enabled for nmea2000. 
> 
>       >  -- i see no way to test it, i have only one linux machine
>       > on 
> 
>       > the boat, perhaps you can tell me how to compare the ntp
>       > results of
> a 
> 
>       > gpsd using a conventional usb gps (u-blox 5) reciever, and
>       > a ntpd
> on 
> 
>       > the gpsd using the information from the nmea2000 bus. 
> 
>       Easy, just send time from both of them and look at "ntpq -p". 
> 
>       O.K. 
> 
>       >  -- as nmea2000 is a CAN bus (network), you need support in 
> 
>       > the CAN driver and perhaps even in the CAN interface
>       > hardware, to 
> 
>       > get a good timestamps. There are own time protocols for
>       > CAN, but
> not 
> 
>       > part ofnmea2000 as far as i know. 
> 
>       Not the point, the timestamps in the nmea2000 GPS messages
> are what 
> 
>       we are looking for.  If those are not supported then nmea2000
> is 
> 
>       useless. 
> 
>       I do not agree, ntp support is needed, but lets do it step by
> step... 
> 
>       >  -- i have spend some time trying to understand the 
> 
>       > interaction of the pps daemon and the other ntp stuff, but
>       > my 
> 
>       > understanding of the subsystem is not good enough to make a
>       > change 
> 
>       > here. My understanding is, the the ntp_link_activate() and 
> 
>       > ntpd_link_deactivate() only allocate/free the the shared
>       > memory 
> 
>       > segment for ntp, and then starts the pps subsystem, that is
> unusable 
> 
>       > for nmea2000 as it is today. 
> 
>       Yes, and no.  ntp_link_activate() also enables the basic
> timestamp 
> 
>       support which should be working for you fine.  You need to
> look deeper 
> 
>       to disable pps support.  But why do you care to disable PPS
> support, is 
> 
>       it breaking something for you?  Turning it off buys you
> nothing. 
> 
>       Because the  
> 
>       ioctl(session->gpsdata.gps_fd, TIOCMIWAIT, PPS_LINE_TIOC) 
> 
>       fails on a CAN socket, and the gpsd_ppsmonitor thread dies,
> there is the bad assumption in this ioctl can be called for every
> interface, if the marco TIOCMIWAIT is defined! 
> 
>       And why start the gpsd_ppsmonitor, if it ides a few seconds
> later... 
> 
>       The error message my confuse other people... 
> 
>       > 
> 
>       >  Question: Does the ntp subsystem (without pps support)
>       > work, 
> 
>       > if there is only the shared memory segment present? 
> 
>       Yes. 
> 
>       > then it is a nice 
> 
>       > option, to move my patches into ntp_link_activate() and 
> 
>       > ntpd_link_deactivate() after allocating/freeing the ntp
>       > shared
> memory 
> 
>       > segment. If this works, it will be for shure a far better
>       > solution!
> 
> 
>       Possibly, send patches and I'll look at it. 
> 
>       O.K. i will change this 
> 
>       RGDS 
> 
>       GARY 
> 
>       
> ---------------------------------------------------------------------------
> 
> 
>       Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend,
> OR 97701
> 
> 
>       address@hidden  Tel:+1(541)382-8588 
> 
>       Reinhard



RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]