[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090208004914.21448.qmail@science.horizon.com>
Date: Sat, 07 Feb 2009 19:49:14 -0500
From: "George Spelvin" <linux@...izon.com>
To: linux@...izon.com, giometti@...eenne.com,
linux-kernel@...r.kernel.org, LinuxPPS@...enneenne.com
Subject: LinuxPPS kernel interface
(Be aware that this is crossposted to linux-kernel and LinuxPPS.
The latter mailing list rejects mail from non-subscribers, so
the discussion on linux-kernel is likely to be more complete.)
LinuxPPS is an implementation of the PPS API from RFC 2783.
That's a function-call interface, and it's up to the implementation
to determine how to partition responsibility between the kernel and
the userspace library.
I just posted to the LinuxPPS maining list a series of patches which
change the semantics of the LinuxPPS kernel interface so most of the
mode bits are per-fd rather than global. You can have one user listening
for assert events and the other listening for clear events.
So far, nothing has changed the interface for any single user; the
only difference is that multiple users now interact less.
One thing I got working is that POLLIN now properly waits until a new
PPS event is available.
That makes it possible to implement the (required) time_pps_fetch()
function without passing the timeout to the PPS_FETCH ioctl. Instead,
time_pps_fetch() can be implemented as a call to poll(2) followed by an
immediate ioctl.
However, other kernel interface cleanups seem possible. Here's my list
of possible kernel interface changes. I'd like some design review and
comments on the ideas.
(Note that some of them are mutually exclusive!)
- Eliminate the timeout argument and the whole struct pps_fdata thing.
Do the timeout with ppoll, and then get the last event.
- Change PPS_FETCH to never wait. Instead, it always immediately returns
the most recently captures PPS events. If you want to wait, use poll.
- Move the PPS_OFFSET feature to user space. That requires making
a pps_handle_t a pointer to a structure containing the offsets.
- Move the PPS_CAPTURE mode bits to use space. Rather than telling
the kernel the mode of the current fd, just have the two different
edges reported by different poll bits (POLLPRI and POLLRDBAND?) which
userspace can wait for whenever it wishes. (POLLIN would get both,
of course.)
- Add a read(2) interface. Suggestions for the format are appreciated.
I imagine an ASCII interface:
assert <sequence> <seconds>.<fraction>\n
clear <sequence> <seconds>.<fraction>\n
But maybe something else?
- Replace PPS_FETCH with the above interface? Or is the dual binary/ASCII
conversion too annoying?
- Add a clock type specification to the kernel interface? Or is
CLOCK_REALTIME always okay?
- I'd like to add support for serial port signals other than DCD.
The 8250 hardware treats CTS and DSR just the same, and one edge of RI
can be trapped. Any idea how to do that? Just instantiate multiple
PPS devices? Should there be a better device naming convention?
- Think about the ECHO flags. The RFC leaves it implementation-defined
which line is used for output, and people seem to use the RTS line.
Bascially, the interrupt handler does a TIOCMBIS/TIOCMBIC ioctl to
toggle the RTS line. Is this okay? How should it interact with CRTSCTS?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists