Re: [gpsd-dev] GPSd re-scan on connect

[Gary E. Miller]

Yo Larry!

On Wed, 10 Apr 2019 16:20:35 -0400
Larry Boyd <address@hidden> wrote:

> >  
> > > There were two threads we were discussing;  
> >
> > When in doubt, best to use one thread per thread.  Not everyone
> > is interested in every discussion.
> >  
> 
> Yes, one thread was regarding the build of gpsd client library for
> AOSP, and the second thread was for having gpsd re-add devices
> directly.

And now we are back to one thread that is offlist...

> > > - The first was relating to building and using the libgps client
> > > library on Android, which would be followed up with a gnss HAL and
> > > eventually gpsd itself.  
> >
> > To be clear, a native build ON an android system, right?
> >  
> 
> The build of AOSP would be on a Linux or OSX host, and that build
> would include libgps to be used on the device running Android.

So a cross compile.  Then scons should be asy to use.

> > > - The second thread involved having gpsd attempt to re-add devices
> > > from the commandline upon client connection if the device list
> > > becomes empty.  
> >
> > Which still seems odd to me.  What devices do you have the come and
> > go? That a udev, or similar, rul can not handle?
> >  
> 
> Any device at all running on an Android host. USB devices on Android
> can be especially challenging since there is a tendency for usb mode
> switching to happen unexpectedly or as a consequence of debugging or
> other use of the device port.

Putting this in gpsd context, do you have GPS on USB that come and go
on Android?

> For example, the SoC on most of these devices (
> https://www.96boards.org/products/ce/) contain only a single USB port.
> Despite having only a single usb port, they are required to comply
> with a specification demanding one device port (for debugging, data
> transfer, etc.) and two host ports. This is accomplished by using a
> switch and a hub. When a connection is made to the device port, the
> USB mode is switched from host to device, and the switch is set to
> the device port rather than the hub, thus whatever is connected to
> the host ports is disconnected for the duration of use of the device
> port.

Ouch.  But how does that apply in yur specific case?

> > > I have attached two patches to this email, note that neither is
> > > ready to be added just yet (in particular, since I have not had
> > > the opportunity to properly test them yet), I was hoping for you
> > > to comment on them before I complete them for submission (which I
> > > will do in the form of signed off git patches).  
> >
> > I'll look at them, but not until other stuff higher in my queue is
> > dealt with.  Specifically the regressions, but also some u-blox
> > stuff.
> >  
> 
> I understand, no rush, thank you.

Good.

> > > readd_devices.patch will check if the device list is empty upon
> > > client connection and re-add those specified on the command line
> > > if there are any. I am confident that this one will work, since
> > > it precisely duplicates what happens when gpsd receives SIGHUP.  
> >
> > Did you reuse the SIGHUP code?  Or cut/paste?  Or?
> >
> > Can you post that patch somewhere that other people can see it for
> > comment? 
> 
> For the most part, I reused the code (copy/paste), but added a
> condition around it to verify that there are NO devices connected.

That is discouraged.  Leads to too much bit rot.  Make the code you
want to reuse a function, then use that in the old and new places.


> So basically, for this code to actually do anything, two conditions
> have to be met;
> 1) There was at least one device specified on the command line,
> 2) There are currently NO devices in the list of connected devices.

OK.

> I did attempt to make the code available for others to see, but like I
> mentioned, it didn't seem to make it to the mailing list;
> http://lists.nongnu.org/archive/html/gpsd-users/2019-04/threads.html
> A few of my messages are showing "message not available", and others
> (ones with patches) don't appear at all.

Thus the needs to post links to patches, not the patches themselves.

The list also wants to be in the To:, not Cc: or Bcc:.

> I'll try with a gitlab snippet later on and see if I can share a link
> to that.

OK.

> > Note: this will be applicable to devices that are connected to the  
> > > system *after* GPSd starts (including devices that may also have
> > > been removed after start), where either the system does not
> > > support udev (i.e. Android), or the device is connected to a bus
> > > that is not supported by udev (i.e. UART).  
> >
> > Android support hot plugging.  How do they do it?
> >  
> 
> Android's ability to handle hotplug events is virtually non-existent
> at the service/daemon level.
> Specifically, all it is capable of is setting device permissions.

Odd.


> > > gpsd_aosp.patch makes it possible to build libgps.so as part of
> > > AOSP. Since scons is not a component of the AOSP build system, it
> > > was necessary to apply configurations manually.  
> >
> > You will regret not using scons.
> >  
> 
> I don't disagree, but I am restricted by what is possible within the
> Android build system.

Juat call scons from your makefile.

> > The majority of this  
> > > patch is the Android.bp (the equivalent of a makefile to the AOSP
> > > build system) and avoiding use of the gpsd_config.h under
> > > Android,  
> >
> > Another decision you will regret.  Much better to hand build a
> > gpsd_config.h rather than patch out every place that includes
> > gpsd_config.h.
> >
> > We are trying to reduce the numer of #ifdef, and this does the
> > opposite. 
> 
> I understand. Would it be preferable to include a "default"
> gpsd_config.h?


Yes, you would create that, for you build environment.  Or let
scons do it for you.

> Or perhaps have gpsd_config.h changed to include
> something like; #ifndef __ANDROID__
> #include "real_gpsd_config.h"
> #endif

No.  We are trying to get rid of #ifdef's, not add them.  Newer
languages, like go, have no equivalent to #ifdef.


> Or do you have any other suggestions about the best way to handle
> this?

Yes, create your own gpsd_config.h

> > > the other change is a hack to redefine gps_maskdump(..) to an
> > > empty string.  
> >
> > Better yet, just make your own copy that dumps the hex, without
> > trying to convert to strings.
> >  
> 
> Ultimately I agree that it would be nice to be able to log on Android,
> however, I think that will end up requiring some more significant
> structural changes to the logging structure of GPSd.

No, easy.  Just copy the machine made copy, remove the defines that
change, and just report the binary mask values.  You really want that
logging.

> > As long as the license is clean then we can add an android directory
> > so others can play with the code.  Is the BSD-2 clause going to work
> > with the HAL, and the rest?
> >  
> 
> I'm open to whatever licensing would be considered appropriate for
> GPSd.

Then BSD-2 clause it is.

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

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgpohNMH1DJBE.pgp
Description: OpenPGP digital signature