Re: [gpsd-dev] Getting the driver-switching logic right

[Eric S. Raymond]

Greg Troxel <address@hidden>:
>   These rules have to interact with device changes.  I think your rules
>   mostly work, but in rule 2, I think a check "and the packet is
>   consistent with the currently selected driver" is needed.

I now think they're overcomplicated.  I'm trying to simplify them.

One large step, already implemented and tested:

commit e2499963397f5c06ef0109f96384d3f4cb5178f3
Author: Eric S. Raymond <address@hidden>
Date:   Sun Oct 13 09:11:31 2013 -0400

    Observer-driver reversion logic.  This is a simple but major change.
    
    Device drivers are now sorted into two categories: observers and 
controllers.
    
    An "observer" is a device type for which there are no control methods
    (that is, no mode switcher, no speed switcher, and no rate switcher).
    Note that observers *are* allowed to require initialization sends (such
    as wakeup probes or commands to set a sentence mix). Important observers
    include Generic NMEA, AIVDM, RTCM2, and RTCM3.
    
    Any other driver is a controller.
    
    The new behavior is simple: each time after you have recognized a
    packet to be handled by an observer driver, *revert the session's
    device-driver pointer to the previous controller* (if we've seen one).
    This means that seeing AIDVM or RTCM packets in an NMEA stream no
    longer causes us to lose information about the type of the driver if
    it had control methods we might want to use later.
    
    All regression tests pass.

I think, maybe, that if the "previous controller" slot gets initialized
with the first driver seen that's not Generic NMEA, that might be the
entire set of rules we need.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature