From: "George Spelvin" <linux@horizon.com>
To: linux@horizon.com, giometti@enneenne.com,
linux-kernel@vger.kernel.org, LinuxPPS@ml.enneenne.com
Subject: LinuxPPS kernel interface
Date: Sat, 07 Feb 2009 19:49:14 -0500 [thread overview]
Message-ID: <20090208004914.21448.qmail@science.horizon.com> (raw)
In-Reply-To: <20090206225326.14093.qmail@science.horizon.com>
(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?
next parent reply other threads:[~2009-02-08 0:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9dd2f03a0810280213v42811184pb14d80f90529d1d5@mail.gmail.com>
[not found] ` <20081028111414.19650.qmail@science.horizon.com>
[not found] ` <20081028144735.GC28518@tekkaman>
[not found] ` <20081028181335.29352.qmail@science.horizon.com>
[not found] ` <20081028181546.GM11339@tekkaman>
[not found] ` <20090206142231.22425.qmail@science.horizon.com>
[not found] ` <20090206143703.GC7975@enneenne.com>
[not found] ` <20090206144752.5195.qmail@science.horizon.com>
[not found] ` <20090206145553.GD7975@enneenne.com>
[not found] ` <20090206145932.10638.qmail@science.horizon.com>
[not found] ` <20090206152156.GE7975@enneenne.com>
[not found] ` <20090206225326.14093.qmail@science.horizon.com>
2009-02-08 0:49 ` George Spelvin [this message]
2009-02-08 1:56 ` Lennart Sorensen
2009-02-08 4:00 ` George Spelvin
2009-02-08 16:35 ` Lennart Sorensen
[not found] ` <498E712F.7080206@xs4all.nl>
2009-02-08 6:09 ` [LinuxPPS] " George Spelvin
2009-02-09 10:17 ` Rodolfo Giometti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090208004914.21448.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=LinuxPPS@ml.enneenne.com \
--cc=giometti@enneenne.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®