gpsd-dev
[Top][All Lists]
Advanced

[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: Sat, 06 Sep 2014 23:19:24 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

Er, I think it was me a couple of years back, I dunno :-)
Just call me Matt.

There are two possible goals to a cygwin/mingw port:

1. A libgps DLL that is capable of being linked into client applications, which can connect to gpsd on another fully-supported machine and give Windows client programs the most natural method of access to unchanged gpsd running on currently-supported platforms;
and
2. A gpsd binary that runs on Windows and provides equivalent functionality to gpsd on POSIX systems.

Cygwin can definitely support the first use case, but probably not the second.
For the second to work, we should talk to the native Windows APIs.

Eric, I take it that you understand the difference between cygwin and mingw? Briefly: - Cygwin is an attempt to provide a POSIX/Linux-like API on Windows, complete with 'fork' emulated in a DLL;
whereas
- Mingw is a port of the GNU toolchain to Windows, with open source headers matching the Windows ABIs.

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?

serial.c is the first cab off the rank: serial port access via the Win32 API is totally different to the current code.

On 06/09/14 22:22, Eric S. Raymond wrote:
Matt <address@hidden>:
Should I list you as Cygwin port maintainer?
Please do. But FYI, my interest in cygwin is mainly as a
stepping-stone towards a high-quality mingw port.
I'll take those patches.

Some work in this direction was done a few years back; that's why there's
a socket_t type.  But whoever was working on it apparently lost interest;
he stopped sending patches.

Do you have a full name you'd like listed?




reply via email to

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