[Top][All Lists]

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

Re: [gpsd-dev] [PATCH]: Handle lack of TIOCEXCL and TIOCNXCL on cygwin

From: Matt
Subject: Re: [gpsd-dev] [PATCH]: Handle lack of TIOCEXCL and TIOCNXCL on cygwin
Date: Sun, 07 Sep 2014 00:07:16 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

On 06/09/14 23:37, Eric S. Raymond wrote:
It's really quite trivial to port gpsd to cygwin. The challenge is
with mingw.
For example, under Win32, serial/USB devices are accessed via
totally different APIs.

The naive approach would be to introduce thin abstraction layers
over the POSIX/Win32 API calls:
non-system-specific libgps[d]APIs in header files, and
system-specific code in the corresponding *.c files, which contained
ugly '#ifdef _WIN32' directives.

Eric, would you accept a series of patches along the lines above?
Yes, though I'd probably end up reorganizing the hell out of the resulting
code to keep the Windows stuff properly isolated.
No, rest assured, precisely this sort of isolation is my intention.
The exploratory cygwin/mingw port I did previously makes me believe that this is possible, with some refactoring of the existing code so that serial/usb/etc access is abstracted away nicely.
serial.c is the first cab off the rank: serial port access via the
Win32 API is totally different to the current code.
Let's give that a try.

I do have misgivings.  I don't really want the support burden implied
by hundreds of millions of clueless Windows users if the port is
anything but fire-and-forget.
There is potentially a great deal of work involved in doing this 100% properly. The most fire-and-forget would probably be a so-called .NET assembly for the client (I know nothing about .NET by the way), and a Windows 'service' for the server (this I do know). Each involves a significant amount of Windows-specific code, which thankfully I think we can isolate cleanly.

A significant amount of effort, but worth it to get further testing exposure/use cases/mindshare.

I earnestly hope that you over-estimate the support burden of naive Windows developers!
Thus, whether we end up carrying it as
an official port will depend on (a) how stable and non-intrusive the WIN32
porting hacks look once they're done, and whether (b) you and I can set up
regression and qualification testing that I have confidence in.
My intention is to focus on getting a Windows port of gpsd talking to one of my devices, serial USB bluetooth or whatever. This will be a major step; once communication occurs at all, we can start along the long road of getting the packet parser/recogniser working.
These are things we can't really estimate in advance.  They have to be
tried out.  Thus, I consider this an exploration mission.
Yeah, exactly. The thing is, I already did an explorative port a couple of years ago, so I have some (little) idea what challenges lie ahead of us.

Getting binaries compiling shouldn't be that hard or intrusive. It's getting access to Win32 serial ports and making sense of the data that worries me. I'm [sightly] scared of the packet recogniser.

reply via email to

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