Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>: > Can I ask why you're using TIOCMIWAIT rather than the Linux PPS api? > Perhaps the kernel api needs extended to support other requirements? Short answer: the question about TIOCMIWAIT support is really about whether hardware like the Oxford Expresso can pass through handshake-line transitions in a form Linux can see. If that isn't true, the PPS API won't work either. My research suggests this is an issue with some popular multiport cards like the Comtrol Rocketport that soft-emulate multiple UARTs in firmware. The longer answer is...it's complicated. GPSD actually supports both methods. We haven't switched over to the PPS API fully because RFC2783 is a touch underspecified and doesn't say how to do association from the tty to the associated PPS device portably, and we're not only concerned with Linux. The maintainer for our PPS code, Gary Miller, is working the problem. The test lab I'm designing is intended for the reference NTP implementation as well as (or more than) GPSD. NTP (and GPSD) need to retain the option to *explicitly* wait on DCD for operating systems like old legacy Unixes or VxWorks or QNX that don't include RFC2783 but might turn out to have a functional equivalent of TIOCMIWAIT to wait on handshake lines when we dig enough. While these are only of minor importance for GPSD, NTP has a lot of legacy customers. One of the things I did last week was factor the TIOCMIWAIT/RFC2738 handling in GPSD into a detachable little library that can be plugged into other programs, with NTP first on the list. I'm pretty sure Gary's pulse-discrimination code is the best there is, and this is a problem that should only be solved once. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
