|
Posted by sergej.galat on June 2, 2008, 11:06 am
Please log in for more thread options wrote:
> My first question is why you'd want to bypass GPSID in the first place? I'd
> like to help make it workable if possible and also understand for future
> versions of the product so we could it up.
Let me describe our use case.
We are developing a hybrid positioning system (HPS) which would take 2
position sources (first is our internal position system and second is
GPS) as the input and 'mix' the data to produce a final position as a
single output for applications. Our goal is not to break the scheme of
how GPS Intermediate Driver and GPS API works with applications and
GPS devices. Instead, we want to keep the system consistent to be
compatible with all existing and future applications, and make
installation of our product transparent for applications and user.
When our application is installed, it registers itself with GPSID and
takes the Hardware Port setting from it to use as GPS source. In other
words HPS puts itself into the middle of the chain Application->GPSID-
>GPS so it becomes Application->GPSID->HPS->GPS .That way an LBS app
would connect to GPS ID port (multiplexed) and get hybrid location
data from our system.
However, we've run into a problem with the internal GPS chip on the
AT&T Tilt handheld, which I believe is common for internal GPS chips.
It seems that GPSID is the only public way to read from the internal
GPS, as the internal GPS itself doesn't provide a separate COM port.
>
> You may not be able to access the underlying GPS poll driver directly in any
> event and even if you can you probably don't want to.
>
> I've advised OEMs that have consulted with me to mark the driver so that
> only trusted applications can access it, in order to make the security
> attack surface of the device a little smaller. Also be aware that the poll
> drivers may be hard-coded to only know how to deal with one application at a
> time, so that even if your app can get at it, there is the chance that it
> would block GPSID and other apps from consuming it. (If you're on a
> targeted device that's OK obviously, but for general purpose code running
> "in the wild" it's a problem.)
That should be OK as HPS is going to be an exclusive listener to the
poll driver.
Applications would connect to GPSID and GPSID would connect to HPS.
> Finally, different OEMs may have different
> poll drivers or even the same OEM may change it slightly from ROM version to
> version.
Isn't it enough to rely on the documented poll interface
(IOCTL_GPS_DRIVER_GET_LOCATION_V1 and GPS_POSITION structure)?
> They only designed themselves & tested to work with GPSID as a
> caller.
We will have to make HPS have no difference with GPSID as a listener
then.
What we can't figure out is how GPSID gets a handle of the poll
driver. We can't find a registry entry, probably that means that the
poll driver is implemented as part of another driver.
I guess the should be a common way for GPSID to find the poll driver,
otherwise it makes GPSID specific for the OEM which doesn't sound
right for me.
Can you provide any help for us on this subject?
Thanks,
Sergey.
| 
XML Sitemap