lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ