RFC2783 日本語訳
2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version1.0. J. Mogul, D. Mills, J. Brittenson, J. Stone, U. Windl. March 2000. (Format: TXT=61421 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Mogul
Request for Comments: 2783 Compaq WRL
Category: Informational D. Mills
University of Delaware
J. Brittenson
Sun
J. Stone
Stanford
U. Windl
Universitaet Regensburg
March 2000
コメントを求めるワーキンググループJ.要人要求をネットワークでつないでください: 2783年のコンパックWRLカテゴリ: 情報のD.は2000年のデラウエア大学のJ.Brittenson Sun J.ストーンスタンフォードU.Windl Universitaetレーゲンスブルクの行進のときにかけめぐります。
Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0
UNIXのようなオペレーティングシステム、バージョン1.0のための1秒あたりのパルスAPI
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
RFC 1589 describes a UNIX kernel implementation model for high- precision time-keeping. This model is meant for use in conjunction with the Network Time Protocol (NTP, RFC 1305), or similar time synchronization protocols. One aspect of this model is an accurate interface to the high-accuracy, one pulse-per-second (PPS) output typically available from precise time sources (such as a GPS or GOES receiver). RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API.
RFC1589は高い精度時間キープのためにUNIXカーネル実装モデルについて説明します。 このモデルは使用のためにNetwork Timeプロトコル(NTP、RFC1305)、または同様の時間同期化プロトコルに関連して意味されます。 このモデルの1つの局面が高精度(正確な時間ソース(GPSかゴエス受信機などの)から通常利用可能な1秒あたり1パルス(PPS)の出力)への正確なインタフェースです。 RFC1589はPPS施設を管理するためにAPIを定義しませんでした、PPSを使用するための携帯用の手段のない作成者をソースに置き去りにして。 このドキュメントはそのようなAPIを指定します。
Mogul, et al. Informational [Page 1] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[1ページ]のRFC API行進
Table of Contents
目次
1 Introduction................................................... 2 2 Data types for representing timestamps......................... 4 2.1 Resolution................................................... 4 2.2 Time scale................................................... 5 3 API............................................................ 5 3.1 PPS abstraction.............................................. 6 3.2 New data structures.......................................... 7 3.3 Mode bit definitions......................................... 10 3.4 New functions................................................ 12 3.4.1 New functions: obtaining PPS sources....................... 13 3.4.2 New functions: setting PPS parameters...................... 14 3.4.3 New functions: access to PPS timestamps.................... 16 3.4.4 New functions: disciplining the kernel timebase............ 18 3.5 Compliance rules............................................. 20 3.5.1 Functions.................................................. 20 3.5.2 Mode bits.................................................. 20 3.6 Examples..................................................... 21 4 Security Considerations........................................ 24 5 Acknowledgements............................................... 24 6 References..................................................... 25 7 Authors' Addresses............................................. 26 A. Extensions and related APIs................................... 27 A.1 Extension: Parameters for the "echo" mechanism............... 27 A.2 Extension: Obtaining information about external clocks....... 27 A.3 Extension: Finding a PPS source.............................. 28 B. Example implementation: PPSDISC Line discipline............... 29 B.1 Example...................................................... 29 C. Available implementations..................................... 30 Full Copyright Statement......................................... 31
1つの序論… タイムスタンプを表すための2 2のデータ型… 4 2.1解決… 4 2.2タイムスケール… 5 3API… 5 3.1 PPS抽象化… 6 3.2の新しいデータ構造… 7 3.3 モードの噛み付いている定義… 10 3.4 新しい機能… 12 3.4 .1 新しい機能: PPSソースを得ます… 13 3.4 .2 新しい機能: PPSパラメタを設定します… 14 3.4 .3 新しい機能: タイムスタンプにPPSにアクセスしてください… 16 3.4 .4 新しい機能: カーネルtimebaseを訓練します… 18 3.5 コンプライアンスは統治されます… 20 3.5 .1 機能します… 20 3.5 .2 モードビット… 20 3.6の例… 21 4 セキュリティ問題… 24 5つの承認… 24 6つの参照箇所… 25 7人の作者のアドレス… 26のA.拡大と関連するAPI… 27 A.1拡張子: 「エコー」メカニズムのためのパラメタ… 27 A.2拡張子: 外部クロックの情報を得ます… 27 A.3拡張子: PPSソースを見つけます… 28B.例の実装: PPSDISC線規律… 29B.1の例… 29 C.の利用可能な実装… 30 完全な著作権宣言文… 31
1 Introduction
1つの序論
RFC 1589 [4] describes a model and programming interface for generic operating system software that manages the system clock and timer functions. The model provides improved accuracy and stability for most workstations and servers using the Network Time Protocol (NTP) [3] or similar time synchronization protocol. The model supports the use of external timing sources, such as the precision pulse-per- second (PPS) signals typically available from precise time sources (such as a GPS or GOES receiver).
RFC1589[4]はシステムクロックとタイマ機能を管理するジェネリックオペレーティングシステムソフトウェアのためにモデルとプログラミングインターフェースについて説明します。 モデルは、Network Timeプロトコル(NTP)[3]か同様の時間同期化プロトコルを使用することで改良された精度と安定性をほとんどのワークステーションとサーバに提供します。 モデルは外部タイミングソースの使用をサポートします、正確な時間ソース(GPSかゴエス受信機などの)から通常利用可能な2番目の(PPS)あたりの精度パルス信号などのように。
However, RFC 1589 did not define an application programming interface (API) for the PPS facility. This document specifies such an interface, for use with UNIX (or UNIX-like) operating systems. Such systems often conform to the "Single UNIX Specification" [5], sometimes known as POSIX.
しかしながら、RFC1589はアプリケーションプログラミングインターフェース(API)をPPS施設と定義しませんでした。 このドキュメントはそのようなインタフェースを指定します、UNIXの、そして、(UNIXのよう)のオペレーティングシステムによる使用のために。そのようなシステムはしばしばPOSIXとして時々知られている「ただ一つのUNIX仕様」[5]に一致しています。
Mogul, et al. Informational [Page 2] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[2ページ]のRFC API行進
One convenient means to provide a PPS signal to a computer system is to connect that signal to a modem-control pin on a serial-line interface to the computer. The Data Carrier Detect (DCD) pin is frequently used for this purpose. Typically, the time-code output of the time source is transmitted to the computer over the same serial line. The computer detects a signal transition on the DCD pin, usually by receiving an interrupt, and records a timestamp as soon as possible.
PPS信号をコンピュータ・システムに供給する1つの便利な手段はコンピュータへのシリアル・ラインのインタフェースでその信号をモデム制御ピンに接続することです。 Data Carrier Detect(DCD)ピンは頻繁にこのために使用されます。 通常、時間ソースの時間コード出力は同じシリアル・ラインでのコンピュータに伝えられます。 コンピュータは、DCDピンの上に通常、中断を受けることによって信号変遷を検出して、できるだけ早く、タイムスタンプを記録します。
Although existing practice has focussed on the use of serial lines and DCD transitions, PPS signals might also be delivered by other kinds of devices. The API specified in this document does not require the use of a serial line, although it may be somewhat biased in that direction.
既存の習慣はシリアル・ラインとDCD変遷の使用に焦点を合わせましたが、また、PPS信号は他の種類のデバイスによって提供されるかもしれません。 本書では指定されたAPIはシリアル・ラインの使用を必要としません、それがその方向にいくらか偏るかもしれませんが。
The typical use of this facility is for the operating system to
record ("capture") a high-resolution timestamp as soon as possible
after it detects a PPS signal transition (usually indicated by an
interrupt). This timestamp can then be made available, with less
stringent delay constraints, to time-related software. The software
can compare the captured timestamp to the received time-code to
accurately discover the offset between the system clock and the
precise time source.
この施設の典型的な使用はPPS信号変遷(通常、中断で示される)を検出した後にオペレーティングシステムができるだけ早く高画質タイムスタンプを記録する(「キャプチャする」)ことです。 そして、このタイムスタンプをそれほど厳しくない遅れ規制で時間関連のソフトウェアに利用可能にすることができます。 ソフトウェアは、正確にシステムクロックと正確な時間ソースの間のオフセットを発見するために容認された時間コードに捕らわれているタイムスタンプをたとえることができます。
The operating system may also deliver the PPS event to a kernel procedure, called the "in-kernel PPS consumer." One example would be the "hardpps()" procedure, described in RFC 1589, which is used to discipline the kernel's internal timebase.
「カーネルにおけるPPS消費者」は、また、オペレーティングシステムがPPSイベントをカーネル手順に提供するかもしれないと呼びました。 1つの例がカーネルの内部のtimebaseを訓練するのに用いられるRFC1589で説明された"hardpps()"手順でしょう。
The API specified in this document allows for one or more signal sources attached to a computer system to provide PPS inputs, at the option of user-level software. User-level software may obtain signal-transition timestamps for any of these PPS sources. User- level software may optionally specify at most one of these PPS sources to be used to discipline the system's internal timebase.
本書では指定されたAPIは、コンピュータ・システムに取り付けられた1つ以上の信号ソースが入力をPPSに供給するのを許容します、ユーザレベルソフトウェアの選択のときに。 ユーザレベルソフトウェアはこれらのPPSソースのいずれとしても信号変遷タイムスタンプを得るかもしれません。 ユーザレベルソフトウェアは、システムの内部のtimebaseを訓練するのに使用されるために任意にこれらのPPSソースのひとりを高々指定するかもしれません。
Although the primary purpose of this API is for capturing true pulse-per-second events, the API may also be used for accurately timestamping events of other periods, or even aperiodic events, when these can be expressed as signal transitions.
このAPIのプライマリ目的は本当の1秒あたりのパルスイベントを得るものですが、また、APIは正確に他の期間、または非周期的のイベントさえのイベントをtimestampingするのに使用されるかもしれません、信号変遷としてこれらを言い表すことができるとき。
This document does not define internal details of how the API must be implemented, and does not specify constraints on the accuracy, resolution, or latency of the PPS feature. However, the utility of this feature is inversely proportional to the delay (and variance of delay), and implementors are encouraged to take this seriously.
このドキュメントは、どうAPIを実装しなければならないかに関する内部の詳細を定義しないで、またPPSの特徴の精度、解決、または潜在で規制を指定しません。 しかしながら、この特徴のユーティリティは逆に遅れ(そして、遅れの変化)に変化しています、そして、作成者が真剣にこれを受け止めるよう奨励されます。
Mogul, et al. Informational [Page 3] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[3ページ]のRFC API行進
In principle, the rate of events to be captured, or the frequency of the signals, can range from once per day (or less often) to several thousand per second. However, since in most implementations the timestamping function will be implemented as a processor interrupt at a relatively high priority, it is prudent to limit the rate of such events. This may be done either by mechanisms in the hardware that generates the signals, or by the operating system.
原則として、得られるイベントのレート、または信号の頻度が(よりしばしば)1日あたりの一度から数1秒あたり1,000に変化できます。 しかしながら、timestamping機能がプロセッサ割込みとして比較的高い優先度でほとんどの実装では、実装されるので、そのようなイベントのレートを制限するのは慎重です。 信号を生成するハードウェアのメカニズム、またはオペレーティングシステムでこれをするかもしれません。
2 Data types for representing timestamps
タイムスタンプを表すための2つのデータ型
Computer systems use various representations of time. Because this API is concerned with the provision of high-accuracy, high-resolution time information, the choice of representation is significant. (Here we consider only binary representations, not human-format representations.)
コンピュータ・システムは時間の様々な表現を使用します。 このAPIは高精度、高画質時間情報の支給に関係があるので、表現の選択は重要です。 (ここで、私たちは、人間の形式ではなく、唯一の2進法表示が表現であると考えます。)
The two interesting questions are:
2つの面白い質問は以下の通りです。
1. what is the resolution of the representation?
1. 表現の解決は何ですか?
2. what time scale is represented?
2. スケールは何時に表されますか?
These questions often lead to contentious arguments. Since this API is intended for use with NTP and POSIX-compliant systems, however, we can limit the choices to representations compatible with existing NTP and POSIX practice, even if that practice is considered "wrong" in some quarters.
これらの質問はしばしば議論好きな議論につながります。 しかしながら、このAPIが使用のためにNTPとPOSIX対応することのシステムで意図するので、私たちは選択を既存のNTPとPOSIX習慣とのコンパチブル表現に制限できます、その習慣がいくつかの四半期に「間違っている」と考えられても。
2.1 Resolution
2.1 解決
In the NTP protocol, "timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits [...] The precision of this representation is about 200 picoseconds" [3].
NTPプロトコルで、「タイムスタンプは秒に64ビットの未署名の固定小数点数として1900年1月1日の0hに比例して表されます」。 最後の32ビット[…]の最初の32ビットと小数部には整数部があります。 「この表現の精度はおよそ200のピコセコンドです」という[3]。
However, most computer systems cannot measure time to this resolution (this represents a clock rate of 5 GHz). The POSIX gettimeofday() function returns a "struct timeval" value, with a resolution of 1 microsecond. The POSIX clock_gettime() function returns a "struct timespec" value, with a resolution of 1 nanosecond.
しかしながら、ほとんどのコンピュータ・システムはこの解決(これは5ギガヘルツのクロックレートを表す)への測定時間がそうすることができません。 POSIX gettimeofday()機能は1マイクロセカンドの解決で"struct timeval"値を返します。 POSIX時計_gettime()機能は1ナノ秒の解決で"struct timespec"値を返します。
This API uses an extensible representation, but defaults to the "struct timespec" representation.
このAPIは、広げることができる表現を使用しますが、"struct timespec"表現をデフォルトとします。
Mogul, et al. Informational [Page 4] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[4ページ]のRFC API行進
2.2 Time scale
2.2 タイムスケール
Several different time scales have been proposed for use in computer systems. UTC and TAI are the two obvious candidates.
いくつかの異なったタイムスケールがコンピュータ・システムにおける使用のために提案されました。UTCとTAIは2人の明白な候補です。
Some people would prefer the use of TAI, which is identical to UTC except that it does not correct for leap seconds. Their preference for TAI stems from the difficulty of computing precise time differences when leap seconds are involved, especially when using times in the future (for which the exact number of leap seconds is, in general, unknowable).
人々の中には飛躍のために秒を修正しないのを除いて、UTCと同じTAIの使用を好む人もいるでしょう。 TAIのための彼らの好みは飛躍秒がかかわるとき特に将来(一般に、飛躍秒のはっきりした数が不可知である)回を使用するとき正確な時差を計算するという困難によります。
However, POSIX and NTP both use UTC, albeit with different base dates. Given that support for TAI would, in general, require other changes to the POSIX specification, this API uses the POSIX base date of 00:00 January 1, 1970 UTC, and conforms to the POSIX use of the UTC time scale.
しかしながら、異なったベース期日で使用しますが、POSIXとNTPはともにUTCを使用します。 TAIのサポートが一般にPOSIX仕様への他の変化を必要とするなら、このAPIは、1970年1月1日UTC00:00のPOSIXベース日付を使用して、UTCタイムスケールのPOSIX使用に従います。
3 API
3 アピ
A PPS facility can be used in two different ways:
2つの異なった方法でPPS施設を使用できます:
1. An application can obtain a timestamp, using the system's
internal timebase, for the most recent PPS event.
1. 最新のPPSイベントにシステムの内部のtimebaseを使用して、アプリケーションはタイムスタンプを得ることができます。
2. The kernel may directly utilize PPS events to discipline its
internal timebase, thereby providing highly accurate time to
all applications.
2. カーネルは内部のtimebaseを訓練するのに直接PPSイベントを利用して、その結果、高精度な時間をすべてのアプリケーションに提供するかもしれません。
This API supports both uses, individually or in combination. The timestamping feature may be used on any number of PPS sources simultaneously; the timebase-disciplining feature may be used with at most one PPS source.
このAPIは個別か組み合わせにおける両方の用途をサポートします。 timestampingの特徴は同時に、いろいろなPPSソースの上で使用されるかもしれません。 timebaseを訓練している特徴は高々1つのPPSソースと共に使用されるかもしれません。
Although the proper implementation of this API requires support from the kernel of a UNIX system, this document defines the API in terms of a set of library routines. This gives the implementor some freedom to divide the effort between kernel code and library code (different divisions might be appropriate on microkernels and monolithic kernels, for example).
このAPIの適切な履行はUNIXシステムのカーネルから支持を要しますが、このドキュメントは1セットのライブラリ・ルーチンでAPIを定義します。 これはカーネルコードとライブラリコードの間で取り組みを分割する何らかの自由を作成者に与えます(例えば、異なった部門はマイクロカーネルとモノリシックカーネルで適切であるかもしれません)。
Mogul, et al. Informational [Page 5] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[5ページ]のRFC API行進
3.1 PPS abstraction
3.1 PPS抽象化
A PPS signal consists of a series of pulses, each with an "asserted" (logical true) phase, and a "clear" (logical false) phase. The two phases may be of different lengths. The API may capture an "assert timestamp" at the moment of the transition into the asserted phase, and a "clear timestamp" at the moment of the transition into the clear phase.
PPS信号はパルスのaシリーズから成ります、それぞれ「断言」で(論理的である、本当に)、フェーズ、およびa「明確な」(論理的な偽)フェーズ。 二相は異なった長さのものであるかもしれません。 APIは断言されたフェーズへの変遷の瞬間の「タイムスタンプについて断言してください」、および変遷の瞬間の「明確なタイムスタンプ」を明確なフェーズにキャプチャするかもしれません。
The specific assignment of the logical values "true" and "false" with specific voltages of a PPS signal, if applicable, is outside the scope of this specification. However, these assignments SHOULD be consistent with applicable standards. Implementors of PPS sources SHOULD document these assignments.
適切であるなら、PPS信号の特定の電圧で「本当」の、そして、「誤った」論理的な値の特定の課題はこの仕様の範囲の外のそうです。 しかしながら、これらの課題SHOULD、適用規格と一致してください。 PPSソースSHOULDの作成者はこれらの課題を記録します。
Reminder to implementors of DCD-based PPS support: TTL and RS-
232C (V.24/V.28) interfaces both define the "true" state as the
one having the highest positive voltage. TTL defines a nominal
absence of voltage as the "false" state, but RS-232C (V.24/V.28)
defines the "false" state by the presence of a negative voltage.
DCDベースのPPSサポートの作成者への思い出させるもの: TTLとRS232C(V.24/V.28)インタフェースはともに「本当」の状態を持っている中で正の電圧最も高いものと定義します。 TTLは「誤った」状態と電圧の名目上の欠如を定義しますが、RS-232C(V.24/V.28)は負の電圧の存在で「誤った」状態を定義します。
The API supports the direct provision of PPS events (and timestamps) to an in-kernel PPS consumer. This could be the function called "hardpps()", as described in RFC 1589 [4], but the API does not require the kernel implementation to use that function name internally. The current version of the API supports at most one in- kernel PPS consumer, and does not provide a way to explicitly name it. The implementation SHOULD impose access controls on the use of this feature.
APIはPPSイベント(そして、タイムスタンプ)のダイレクト支給をカーネルにおけるPPS消費者にサポートします。 これはRFC1589[4]で説明されるように"hardpps()"と呼ばれる機能であるかもしれませんが、APIは、内部的にその機能名を使用するためにカーネル実装を必要としません。 APIの最新版は、あるコネカーネルPPS消費者を高々サポートして、明らかにそれを命名する方法を提供しません。 実装SHOULDはこの特徴の使用にアクセス制御を課します。
The API optionally supports an "echo" feature, in which events on the incoming PPS signal may be reflected through software, after the capture of the corresponding timestamp, to an output signal pin. This feature may be used to discover an upper bound on the actual delay between the edges of the PPS signal and the capture of the timestamps; such information may be useful in precise calibration of the system.
APIは任意に、入って来るPPS信号の上のイベントがソフトウェアを通して反映されるかもしれない「エコー」の特徴をサポートします、対応するタイムスタンプの捕獲の後に、出力信号ピンに。 この特徴はPPS信号の縁とタイムスタンプの捕獲の間の実際の遅れで上限を発見するのに使用されるかもしれません。 そのような情報はシステムの正確な較正で役に立つかもしれません。
The designation of an output pin for the echo signal, and sense and shape of the output transition, is outside the scope of this specification, but SHOULD be documented for each implementation. The output pin MAY also undergo transitions at other times besides those caused by PPS input events.
しかし、この仕様、SHOULDの範囲の外にエコー信号、および感覚のための出力ピンと出力変遷の形の名称があります。各実装のために、記録されます。 また、出力ピンを他の時にPPS入力イベントによって引き起こされたもの以外に変化させるかもしれません。
Note: this allows an implementation of the echo feature to
generate an output pulse per input pulse, or an output edge per
input pulse, or an output pulse per input edge. It also allows the
same signal pin to be used for several purposes simultaneously.
以下に注意してください。 これは1入力パルス単位で出力パルスを生成するか、または1入力パルス単位で出力縁を生成するエコーの特徴の実装、または入力縁あたり1出力パルスを許容します。 また、それは、同じ信号ピンが同時にいくつかの目的に使用されるのを許容します。
Mogul, et al. Informational [Page 6] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[6ページ]のRFC API行進
Also, the API optionally provides an application with the ability to specify an offset value to be applied to captured timestamps. This can be used to correct for cable and/or radio-wave propagation delays, or to compensate for systematic jitter in the external signal. The implementation SHOULD impose access controls on the use of this feature.
また、APIは任意に捕らわれているタイムスタンプに適用されるためにオフセット値を指定する能力をアプリケーションに提供します。 ケーブル、そして/または、電磁波伝播のために遅れを修正するか、または外部信号における系統的なジターを補うのにこれを使用できます。 実装SHOULDはこの特徴の使用にアクセス制御を課します。
3.2 New data structures
3.2 新しいデータ構造
The data structure declarations and symbol definitions for this API will appear in the header file <sys/timepps.h>. The header file MUST define all constants described in this specification, even if they are not supported by the implementation.
このAPIのためのデータ構造宣言とシンボル定義はヘッダーファイル<sys/timepps.h>に現れるでしょう。 ヘッダーファイルはそれらが実装によってサポートされないでもこの仕様で説明されたすべての定数を定義しなければなりません。
The API includes several implementation-specific types:
APIは数人の実装特定のタイプを含んでいます:
typedef ... pps_handle_t; /* represents a PPS source */
typedef…pps_ハンドル_t。 /*はPPSソース*/を表します。
typedef unsigned ... pps_seq_t; /* sequence number */
typedefの未署名の…pps_seq_t。 /*一連番号*/
The "pps_handle_t" type is an opaque scalar type used to represent a PPS source within the API.
「pps_ハンドル_t」タイプはAPIの中でPPSソースの代理をするのに使用される分っているスカラ型です。
The "pps_seq_t" type is an unsigned integer data type of at least 32 bits.
「pps_seq_t」タイプは少なくとも32ビットの符号のない整数データ型です。
The precise declaration of the pps_handle_t and pps_seq_t types is system-dependent.
pps_ハンドル_tとpps_seq_tタイプの正確な宣言はシステム依存しています。
The API imports the standard POSIX definition for this data type:
APIは、標準のPOSIXがこのデータ型のための定義であるとインポートします:
struct timespec {
time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
struct timespec時間_t tv_秒; /*秒*/長いtv_nsec;/*数ナノ秒*/。
The API defines this structure as an internal (not "on the wire") representation of the NTP "64-bit unsigned fixed-point" timestamp format [3]:
APIはNTP「64ビットの未署名の定点」タイムスタンプ形式[3]の内部(どんな「ワイヤ」のも)の表現とこの構造を定義します:
typedef struct ntp_fp {
unsigned int integral;
unsigned int fractional;
} ntp_fp_t;
typedef struct ntp_fpの未署名のint不可欠; 未署名のint断片的;のntp_fp_t。
The two fields in this structure may be declared as any unsigned integral type, each of at least 32 bits.
この構造の2つの分野がそれぞれ少なくとも32ビットのどんな未署名の整数型としても宣言されるかもしれません。
Mogul, et al. Informational [Page 7] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[7ページ]のRFC API行進
The API defines this new union as an extensible type for representing times:
APIは回を表すための広げることができるタイプとこの新しい組合を定義します:
typedef union pps_timeu {
struct timespec tspec;
ntp_fp_t ntpfp;
unsigned long longpad[3];
} pps_timeu_t;
typedef組合pps_timeu struct timespec tspec; _ntp_fp t ntpfp; 未署名の長いlongpad[3];pps_timeu_t。
Future revisions of this specification may add more fields to this union.
この仕様の今後の改正は、より多くの分野をこの組合に追加するかもしれません。
Note: adding a field to this union that is larger than
3*sizeof(long) will break binary compatibility.
以下に注意してください。 3*sizeof(長い)がバイナリ互換性を壊すより大きいこの組合に分野を追加します。
The API defines these new data structures:
APIはこれらの新しいデータ構造を定義します:
typedef struct {
pps_seq_t assert_sequence; /* assert event seq # */
pps_seq_t clear_sequence; /* clear event seq # */
pps_timeu_t assert_tu;
pps_timeu_t clear_tu;
int current_mode; /* current mode bits */
} pps_info_t;
{pps_seq_tは、*明確なイベント_系列; *がイベントのseq#*/ppsの_のseq_t明確な_系列であると断言する/;/seqな#*/pps_timeu_tが、_がtuであると断言すると断言します; pps_timeuの_のt明確な_*tu; intの現在の_モード;/現在のモードビット*/}というtypedef struct pps_インフォメーション_t。
#define assert_timestamp assert_tu.tspec
#define clear_timestamp clear_tu.tspec
#定義、_タイムスタンプが、_tu.tspec#が明確な_タイムスタンプの明確な_tu.tspecを定義すると断言すると断言してください。
#define assert_timestamp_ntpfp assert_tu.ntpfp
#define clear_timestamp_ntpfp clear_tu.ntpfp
#定義、_タイムスタンプ_ntpfpが、_tu.ntpfp#が_明確な_タイムスタンプのntpfpに明確な_tu.ntpfpを定義すると断言すると断言してください。
typedef struct {
int api_version; /* API version # */
int mode; /* mode bits */
pps_timeu_t assert_off_tu;
pps_timeu_t clear_off_tu;
} pps_params_t;
typedef struct*/pps_timeu_tが_であると断言する*モードオフさint api_バージョン; /*APIバージョン#*/intモード;/ビットの_tu; _tuのpps_timeu_t明確な_;pps_params_t。
#define assert_offset assert_off_tu.tspec
#define clear_offset clear_off_tu.tspec
#定義、_相殺されて、__tu.tspecで_tu.tspec#では、明確な_オフセット明確な_を定義するように断言するように断言してください。
#define assert_offset_ntpfp assert_off_tu.ntpfp
#define clear_offset_ntpfp clear_off_tu.ntpfp
#定義、__相殺されて、__tu.ntpfpで_tu.ntpfp#では、明確な_オフセット_ntpfp明確な_を定義するようにntpfpに断言するように断言してください。
The "pps_info_t" type is returned on an inquiry to PPS source. It contains the timestamps for the most recent assert event, and the most recent clear event. The order in which these events were actually received is defined by the timetamps, not by any other
「pps_インフォメーション_t」タイプをPPSソースへの問い合せに返します。 タイムスタンプを含んでいる、最新である、イベント、および最新の明確なイベントについて断言してください。 これらのイベントが実際に受け取られたオーダーはいかなる他のないtimetampsによっても定義されます。
Mogul, et al. Informational [Page 8] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[8ページ]のRFC API行進
aspect of the specification. Each timestamp field represents the value of the operating system's internal timebase when the timestamped event occurred, or as close as possible to that time (with the optional addition of a specified offset). The current_mode field contains the value of the mode bits (see section 3.3) at the time of the most recent transition was captured for this PPS source. An application can use current_mode to discover the format of the timestamps returned.
仕様の局面。 timestampedイベントができるだけその時(指定されたオフセットの任意の追加がある)の近くに起こったとき、それぞれのタイムスタンプ分野はオペレーティングシステムの内部のtimebaseの値を表します。 現在の_モード分野は最新の変遷時点のビット(セクション3.3を見る)が得られたモードの値をこのPPSソースに含んでいます。 アプリケーションは、タイムスタンプの形式が戻ったと発見するのに現在の_モードを使用できます。
The assert_sequence number increases once per captured assert timestamp. Its initial value is undefined. If incremented past the largest value for the type, the next value is zero. The clear_sequence number increases once per captured clear timestamp. Its initial value is undefined, and may be different from the initial value of assert_sequence. If incremented past the largest value for the type, the next value is zero. Due to possible signal loss or excessive signal noise, the assert-sequence number and the clear- sequence number might not always increase in step with each other.
_がキャプチャされて、一連番号が一度増加する単位タイムスタンプについて断言すると断言してください。 初期の値は未定義です。 タイプのために最も大きい値の先で増加されるなら、次の値はゼロです。 明確な_一連番号は捕らわれている明確なタイムスタンプに一度増加します。 初期の値が未定義であり、初期の値と異なるかもしれない、_が系列であると断言してください。 タイプのために最も大きい値の先で増加されるなら、次の値はゼロです。 可能な信号損失か過度の信号雑音のため、一連番号について断言して、明確な一連番号は互いと共にステップをいつも増やすかもしれないというわけではありません。
Note that these sequence numbers are most useful in applications
where events other than PPS transitions are to be captured, which
might be involved in a precision stopwatch application, for
example. In such cases, the sequence numbers may be used to detect
overruns, where the application has missed one or more events.
They may also be used to detect an excessive event rate, or to
detect that an event has failed to occur between two calls to the
time_pps_fetch() function (defined later).
例えば、精度ストップウォッチアプリケーションでこれらの一連番号が捕らわれるPPS変遷以外のイベントがことであるアプリケーションで最も役に立つことに注意してください(かかわるかもしれません)。 そのような場合、一連番号は超過を検出するのに使用されるかもしれません、アプリケーションが1つ以上のイベントを逃したところで。 また、それらが過度のイベント率を検出するのに使用されるかもしれませんか、またはそれを検出するために、イベントは2つの呼び出しの間に時間_pps_フェッチ()機能(後で定義される)に起こっていません。
In order to obtain an uninterrupted series of sequence numbers
(and hence of event timestamps), it may be necessary to sample the
pps_info_t values at a rate somewhat faster than the underlying
event rate. For example, an application interested in both assert
and clear timestamps may need to sample at least twice per second.
Proper use of the sequence numbers allows an application to
discover if it has missed any event timestamps due to an
insufficient sampling rate.
とぎれないシリーズの一連番号を得る、(したがって、イベントタイムスタンプ、)、基本的なイベント率よりいくらか速い速度でpps_インフォメーション_t値を抽出するのが必要であるかもしれません。 例えば、両方に関心があるアプリケーションは断言して、1秒単位で少なくとも二度抽出します明確なタイムスタンプが、必要があるかもしれない。 一連番号の適切な使用で、アプリケーションは、それが不十分な標本抽出率のため何かイベントタイムスタンプを逃したかどうか発見できます。
The pps_params_t data type is used to discover and modify parameters of a PPS source. The data type includes a mode field, described in section 3.3. It also includes an api_version field, a read-only value giving the version of the API. Currently, the only defined value is:
pps_params_tデータ型は、PPSソースのパラメタを発見して、変更するのに使用されます。 データ型はセクション3.3で説明されたモード分野を含んでいます。 また、それはapi_バージョン分野、APIのバージョンを与える書き込み禁止値を含んでいます。 現在、唯一の定義された値は以下の通りです。
#define PPS_API_VERS_1 1
#PPS_アピ_VERS_1 1を定義してください。
This field is present to enable binary compatibility with future versions of the API.
この分野は、APIの将来のバージョンでバイナリ互換性を可能にするために存在しています。
Mogul, et al. Informational [Page 9] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[9ページ]のRFC API行進
Note: the term "read-only" in this specification means that an
application cannot modify the relevant data item; only the
implementation can modify the value. The implementation MUST
ignore attempts by the application to modify a read-only field.
以下に注意してください。 「書き込み禁止」というこの仕様による用語は、アプリケーションが関連データ項目を変更できないことを意味します。 実装だけが値を変更できます。 実装は、書き込み禁止分野を変更するためにアプリケーションで試みを無視しなければなりません。
As an OPTIONAL feature of the API, the implementation MAY support adding offsets to the timestamps that are captured. (Values of type "struct timespec" can represent negative offsets.) The assert_offset field of a pps_params_t value specifies a value to be added to generate a captured assert_timestamp. The clear_offset of a pps_params_t value field specifies a value to be added to generate a captured clear_timestamp. Since the offsets, if any, apply to all users of a given PPS source, the implementation SHOULD impose access controls on the use of this feature; for example, allowing only the super-user to set the offset values. The default value for both offsets is zero.
APIのOPTIONALの特徴として、実装は捕らわれているタイムスタンプへのオフセットを付加にサポートするかもしれません。 (タイプ"struct timespec"の値は否定的オフセットを表すことができます。) __tがキャプチャされたaを生成するために加えられるために値を指定するのを評価するpps_paramsのオフセット分野が、_がタイムスタンプであると断言すると断言してください。 pps_params_t値の分野の明確な_オフセットは、捕らわれている明確な_タイムスタンプを生成するために加えられるために値を指定します。 もしあればオフセットが与えられたPPSソースのすべてのユーザに適用されるので、実装SHOULDはこの特徴の使用にアクセス制御を課します。 例えば、スーパーユーザだけがオフセット値を設定するのを許容すること。 両方のオフセットのためのデフォルト値はゼロです。
3.3 Mode bit definitions
3.3 モードの噛み付いている定義
A set of mode bits is associated with each PPS source.
1セットのモードビットはそれぞれのPPSソースに関連しています。
The bits in the mode field of the pps_params_t type are:
pps_params_tタイプのモード分野のビットは以下の通りです。
/* Device/implementation parameters */
#define PPS_CAPTUREASSERT 0x01
#define PPS_CAPTURECLEAR 0x02
#define PPS_CAPTUREBOTH 0x03
/*デバイス/実装パラメタ*/#、がCAPTUREASSERT0×01#、が定義するPPS_を定義する、PPS_CAPTURECLEAR0×02#、はPPS_CAPTUREBOTH0x03を定義します。
#define PPS_OFFSETASSERT 0x10
#define PPS_OFFSETCLEAR 0x20
#定義、PPS_OFFSETASSERT0x10#、はPPS_OFFSETCLEAR0x20を定義します。
#define PPS_CANWAIT 0x100
#define PPS_CANPOLL 0x200
#定義、PPS_CANWAIT0x100#、はPPS_CANPOLL0x200を定義します。
/* Kernel actions */
#define PPS_ECHOASSERT 0x40
#define PPS_ECHOCLEAR 0x80
/*カーネル動作*/#、がECHOASSERT0x40#、が定義するPPS_を定義する、PPS_ECHOCLEAR0x80
/* Timestamp formats */
#define PPS_TSFMT_TSPEC 0x1000
#define PPS_TSFMT_NTPFP 0x2000
/*タイムスタンプ形式*/#がTSPEC0×1000#、が定義するPPS_TSFMT_を定義する、PPS_TSFMT_NTPFP0x2000
These mode bits are divided into three categories:
これらのモードビットは3つのカテゴリに分割されます:
1. Device/implementation parameters: These are parameters either
of the device or of the implementation. If the implementation
allows these to be changed, then these bits are read/write for
users with sufficient privilege (such as the super-user), and
1. デバイス/実装パラメタ: これらはデバイスか実装のパラメタです。 そして実装がこれらを許容するなら変えます、次に、/がこれらのビットに読み込まれるということになるようにユーザのために十分な特権(スーパーユーザなどの)で書いてください。
Mogul, et al. Informational [Page 10] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[10ページ]のRFC API行進
read-only for other users. If the implementation does not
allow these bits to be changed, they are read-only.
他のユーザのための書き込み禁止。 これらのビットが実装で変化しないなら、それらは書き込み禁止です。
2. Kernel actions: These bits specify certain kernel actions to
be taken on arrival of a signal. If the implementation
supports one of these actions, then the corresponding bit is
read/write for users with sufficient privilege (such as the
super-user), and read-only for other users. If the
implementation does not support the action, the corresponding
bit is always zero.
2. カーネル動作: これらのビットは、到着次第信号について取るためにあるカーネル動作を指定します。 実装がこれらの動作の1つをサポートするなら、対応するビットは十分な特権(スーパーユーザなどの)をもっているユーザ、および他のユーザのための書き込み禁止のために読むか、または書くことです。 実装が動作をサポートしないなら、いつも対応するビットはゼロです。
3. Timestamp formats: These bits indicate the set of timestamp
formats available for the device. They are always read-only.
3. タイムスタンプ形式: これらのビットはデバイスに利用可能なタイムスタンプ形式のセットを示します。 いつもそれらは書き込み禁止です。
In more detail, the meanings of the Device/implementation parameter mode bits are:
さらに詳細に、Device/実装パラメタモードビットの意味は以下の通りです。
PPS_CAPTUREASSERT
If this bit is set, the assert timestamp for the
associated PPS source will be captured.
これが噛み付いたPPS_CAPTUREASSERT Ifが用意ができている、関連PPSソースへのタイムスタンプが得られると断言してください。
PPS_CAPTURECLEAR
If this bit is set, the clear timestamp for the
associated PPS source will be captured.
これが噛み付いたPPS_CAPTURECLEAR Ifは用意ができて、関連PPSソースへの明確なタイムスタンプを得るでしょう。
PPS_CAPTUREBOTH Defined as the union of PPS_CAPTUREASSERT and
PPS_CAPTURECLEAR, for convenience.
PPS_CAPTUREASSERTの組合としてのPPS_CAPTUREBOTH Definedと便宜のためのPPS_CAPTURECLEAR。
PPS_OFFSETASSERT
If set, the assert_offset value is added to the
current value of the operating system's internal
timebase in order to generate the captured
assert_timestamp.
_オフセット価値が捕らわれを生成するためにオペレーティングシステムの内部のtimebaseの現行価値に高められると断言してください。PPS_OFFSETASSERT Ifがセットした、_がタイムスタンプであると断言してください。
PPS_OFFSETCLEAR If set, the clear_offset value is added to the
current value of the operating system's internal
timebase in order to generate the captured
clear_timestamp.
OFFSETCLEAR Ifが設定するPPS_、_の明確なオフセット価値は、捕らわれている明確な_タイムスタンプを生成するためにオペレーティングシステムの内部のtimebaseの現行価値に高められます。
PPS_CANWAIT If set, the application may request that the
time_pps_fetch() function (see section 3.4.3) should
block until the next timestamp arrives. Note: this
mode bit is read-only.
CANWAIT Ifが設定するPPS_、アプリケーションは_pps_フェッチ()機能(セクション3.4.3を見る)が妨げるべきである次のタイムスタンプが到着するまでの時間、それを要求するかもしれません。 以下に注意してください。 このモードビットは書き込み禁止です。
PPS_CANPOLL This bit is reserved for future use. An application
SHOULD NOT depend on any functionality implied either
by its presence or by its absence.
PPS_CANPOLL Thisビットは今後の使用のために予約されます。 アプリケーションSHOULD NOTは存在かその不在によって暗示しているどんな機能性にも依存します。
Mogul, et al. Informational [Page 11] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[11ページ]のRFC API行進
If neither PPS_CAPTUREASSERT nor PPS_CAPTURECLEAR is set, no valid timestamp will be available via the API.
PPS_CAPTUREASSERTもPPS_CAPTURECLEARも用意ができていないと、どんな有効なタイムスタンプもAPIを通して利用可能にならないでしょう。
The meanings of the Kernel action mode bits are:
Kernel動作モードビットの意味は以下の通りです。
PPS_ECHOASSERT If set, after the capture of an assert timestamp,
the implementation generates a signal transition as
rapidly as possible on an output signal pin. This
MUST NOT affect the delay between the PPS source's
transition to the asserted phase and the capture of
the assert timestamp.
PPS_ECHOASSERT Ifが捕獲の後にセットした、タイムスタンプについて断言してください、そして、実装は早急に出力信号ピンの上に信号の変遷を生成します。 これが断言されたフェーズへのPPSソースの変遷と捕獲の間の遅れに影響してはいけない、タイムスタンプについて断言してください。
PPS_ECHOCLEAR If set, after the capture of a clear timestamp, the
implementation generates a signal transition as
rapidly as possible on an output signal pin. This
MUST NOT affect the delay between the PPS source's
transition to the clear phase and the capture of the
clear timestamp.
ECHOCLEAR Ifが明確なタイムスタンプの捕獲の後に設定するPPS_、実装は早急に出力信号ピンの上に信号が変遷であると生成します。 これは明確なフェーズへのPPSソースの変遷と明確なタイムスタンプの捕獲の間の遅れに影響してはいけません。
The timestamp formats are:
タイムスタンプ形式は以下の通りです。
PPS_TSFMT_TSPEC Timestamps and offsets are represented as values of
type "struct timespec". All implementations MUST
support this format, and this format is the default
unless an application specifies otherwise.
PPS_TSFMT_TSPEC Timestampsとオフセットはタイプ"struct timespec"の値として表されます。 すべての実装がこの形式をサポートしなければなりません、そして、アプリケーションが別の方法で指定しない場合、この形式はデフォルトです。
PPS_TSFMT_NTPFP Timestamps and offsets are represented as values of
type "ntp_fp_t", which corresponds to the NTP
"64-bit unsigned fixed-point" timestamp format [3].
Support for this format is OPTIONAL.
PPS_TSFMT_NTPFP TimestampsとオフセットはNTP「64ビットの未署名の定点」タイムスタンプ形式[3]に対応するタイプ「ntp_fp_t」の値として表されます。 この形式のサポートはOPTIONALです。
Other timestamp format bits may be defined as fields are added to the "pps_timeu_t" union.
他のタイムスタンプ形式ビットは分野が「pps_timeu_t」組合に追加されると定義されるかもしれません。
The operating system may implement all of these mode bits, or just a subset of them. If an attempt is made to set an unsupported mode bit, the API will return an error. If an attempt is made to modify a read-only mode bit, the API will return an error.
オペレーティングシステムは、これらのすべてがモードビット、またはただそれらの部分集合であると実装するかもしれません。 サポートされないモードビットを設定するのを試みをすると、APIは誤りを返すでしょう。 読込み専用モードビットを変更するのを試みをすると、APIは誤りを返すでしょう。
3.4 New functions
3.4 新しい機能
In the description of functions that follows, we use the following function parameters:
続く機能の記述では、私たちは以下の関数パラメータを使用します:
filedes A file descriptor (type: int), for a serial line or
other source of PPS events.
PPSイベントのシリアル・ラインか他の源へのfiledes Aファイルディスクリプタ(タイプ: int)。
Mogul, et al. Informational [Page 12] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[12ページ]のRFC API行進
ppshandle A variable of type "pps_handle_t", as defined in
section 3.2.
セクション3.2で定義されるようなタイプ「pps_ハンドル_t」のppshandle A変数。
ppsinfobuf A record of type "pps_info_t", as defined in
section 3.2.
セクション3.2で定義されるようなタイプ「pps_インフォメーション_t」に関するppsinfobuf A記録。
ppsparams A record of type "pps_params_t", as defined in
section 3.2.
セクション3.2で定義されるようなタイプ「pps_params_t」に関するppsparams A記録。
tsformat An integer with exactly one of the timestamp format
bits set.
ちょうどタイムスタンプ形式ビットの1つがあるtsformat An整数はセットしました。
3.4.1 New functions: obtaining PPS sources
3.4.1 新しい機能: PPSソースを得ます。
The API includes functions to create and destroy PPS source "handles".
APIは、PPSソース「ハンドル」を作成して、破壊するために機能を含んでいます。
SYNOPSIS
構文
int time_pps_create(int filedes, pps_handle_t *handle);
int time_pps_destroy(pps_handle_t handle);
int時間_pps_は(int filedes、pps_ハンドル_t*ハンドル)を作成します。 int時間_pps_は(pps_ハンドル_tハンドル)を破壊します。
DESCRIPTION
記述
All of the other functions in the PPS API operate on PPS handles (type: pps_handle_t). The time_pps_create() is used to convert an already-open UNIX file descriptor, for an appropriate special file, into a PPS handle.
PPS APIでの他の機能のすべてがPPSハンドル(タイプ: pps_ハンドル_t)を作動させます。 _pps_が()を作成する時は、適切な特別なファイルのための既に開いているUNIXファイルディスクリプタをPPSハンドルに変換するために費やされます。
The definition of what special files are appropriate for use with the PPS API is outside the scope of this specification, and may vary based on both operating system implementation, and local system configuration. One typical case is a serial line, whose DCD pin is connected to a source of PPS events.
PPS APIとの使用に、どんな特別なファイルが適切であるかに関する定義は、この仕様の範囲の外にあって、オペレーティングシステム実装とローカルシステム構成の両方に基づいて異なるかもしれません。 1つの典型的なケースがシリアル・ラインです。そのDCDピンはPPSイベントの源に接続されます。
The mode in which the UNIX file descriptor was originally opened affects what operations are allowed on the PPS handle. The time_pps_setparams() and time_pps_kcbind() functions (see sections 3.4.2 and 3.4.4) SHOULD be prohibited by the implementation if the descriptor is open only for reading (O_RDONLY).
UNIXファイルディスクリプタが元々開かれたモードは、どんな操作がPPSハンドルの上に許されているかに影響します。 時間_pps_setparams()と時間_pps_kcbind()機能、(セクション3.4 .2と3.4を見てください、.4)SHOULD、実装で、単に読書(O_RDONLY)において、記述子が開くなら、禁止されてください。
Note: operations on a descriptor opened with an inappropriate mode
might fail with EBADF.
以下に注意してください。 不適当なモードで開かれた記述子における操作はEBADFと共に失敗するかもしれません。
The time_pps_destroy() function makes the PPS handle unusable, and frees any storage that might have been allocated for it. It does not close the associated file descriptor, nor does it change any of the parameter settings for the PPS source.
_pps_が() 機能を破壊する時は、PPSハンドルを使用不可能にして、それのために割り当てられたどんなストレージも解放します。 それは関連ファイルディスクリプタを閉じません、そして、パラメタ設定のいずれもPPSソースに変えません。
Mogul, et al. Informational [Page 13] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[13ページ]のRFC API行進
Note: If this API is adapted to an operating system that does not
follow UNIX conventions for representing an accessible PPS source
as an integer file descriptor, the time_pps_create() function may
take different parameters from those shown here.
以下に注意してください。 このAPIが従わないオペレーティングシステムに適合させられるなら、整数ファイルディスクリプタ、時間_pps_が() 機能を作成しながら理解できるPPSソースの代理をするためのUNIXコンベンションはここに示されたものと異なったパラメタを取るかもしれません。
RETURN VALUES
リターン値
On successful completion, the time_pps_create() function returns 0. Otherwise, a value of -1 is returned and errno is set to indicate the error.
うまくいくのに、完成、時間_pps_は() 機能リターン0を作成します。 さもなければ、-1の値を返します、そして、errnoは誤りを示すように用意ができています。
If called with a valid handle parameter, the time_pps_destroy() function returns 0. Otherwise, it returns -1.
有効なハンドルで呼ばれるなら、パラメタ、時間_pps_は() 機能リターン0を破壊します。 さもなければ、それは-1を返します。
ERRORS
誤り
If the time_pps_create() function fails, errno may be set to one of the following values:
_pps_が() 機能を作成する時が失敗するなら、errnoは以下の値の1つに用意ができるかもしれません:
[EBADF] The filedes parameter is not a valid file descriptor.
[EBADF] filedesパラメタは有効なファイルディスクリプタではありません。
[EOPNOTSUPP] The use of the PPS API is not supported for the file
descriptor.
[EOPNOTSUPP] PPS APIの使用はファイルディスクリプタのためにサポートされません。
[EPERM] The process's effective user ID does not have the
required privileges to use the PPS API.
[EPERM] 過程sの実効ユーザーIDには、PPS APIを使用する必要な特権がありません。
3.4.2 New functions: setting PPS parameters
3.4.2 新しい機能: PPSパラメタを設定します。
The API includes several functions use to set or obtain the parameters of a PPS source.
APIは機能がPPSソースのパラメタを設定するか、または得るのに使用する数個を含んでいます。
SYNOPSIS
構文
int time_pps_setparams(pps_handle_t handle,
const pps_params_t *ppsparams);
int time_pps_getparams(pps_handle_t handle,
pps_params_t *ppsparams);
int time_pps_getcap(pps_handle_t handle, int *mode);
_int時間pps_setparams(pps_ハンドル_tハンドル、const pps_params_t*ppsparams)。 _int時間pps_getparams(pps_ハンドル_tハンドル、pps_params_t*ppsparams)。 _int時間pps_getcap(pps_ハンドル_tハンドル、int*モード)。
DESCRIPTION
記述
A suitably privileged application may use time_pps_setparams() to set the parameters (mode bits and timestamp offsets) for a PPS source. The pps_params_t type is defined in section 3.2; mode bits are defined in section 3.3. An application may use time_pps_getparams() to discover the current settings of the PPS parameters. An application that needs to change only a subset of the existing
適当に特権があるアプリケーションは_パラメタ(モードビットとタイムスタンプオフセット)をPPSソースに設定する時間pps_setparams()を使用するかもしれません。 pps_params_tタイプはセクション3.2で定義されます。 モードビットはセクション3.3で定義されます。 アプリケーションは_PPSパラメタの現在の設定を発見する時間pps_getparams()を使用するかもしれません。 存在の部分集合だけを変える必要があるアプリケーション
Mogul, et al. Informational [Page 14] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[14ページ]のRFC API行進
parameters must first call time_pps_getparams() to obtain the current parameter values, then set the new values using time_pps_setparams().
パラメタは、_時間pps_setparams()を使用することで最初に、_現在のパラメタ値を得る時間pps_getparams()と呼んで、次に、新しい値を設定しなければなりません。
Note: a call to time_pps_setparams() replaces the current values
of all mode bits with those specified via the ppsparams argument,
except those bits whose state cannot be changed. Bits might be
read-only due to access controls, or because they are fixed by the
implementation.
以下に注意してください。 _時間pps_setparams()までの呼び出しはppsparams議論で指定されるそれらにすべてのモードビットの現行価値に取って代わります、状態を変えることができないそれらのビットを除いて。 アクセス制御のためまたはそれらが実装によって修理されているのでビットは書き込み禁止であるかもしれません。
The timestamp format of the assert_offset and clear_offset fields is defined by the mode field. That is, on a call to time_pps_setparams(), the kernel interprets the supplied offset values using the timestamp format given in the mode field of the ppsparams argument. If the requested timestamp format is not supported, the time_pps_setparams() function has no effect and returns an error value. On a call to time_pps_getparams(), the kernel provides the timestamp format of the offsets by setting one of the timestamp format bits in the mode field.
タイムスタンプ形式、_が分野を相殺したのがオフセットの、そして、明確な_がモード分野によって定義されると断言してください。 すなわち、_時間pps_setparams()までの呼び出しのときに、カーネルは、ppsparams議論のモード分野で与えられたタイムスタンプ書式を使用することで供給されたオフセット値を解釈します。 要求されたタイムスタンプ形式がサポートされないなら、時間_pps_setparams()機能は、効き目がなくて、誤り値を返します。 _時間pps_getparams()までの呼び出しのときに、カーネルは、タイムスタンプ形式ビットの1つをモード分野にはめ込むことによって、オフセットのタイムスタンプ形式を提供します。
Note: an application that uses time_pps_getparams() to read the
current offset values cannot specify which format is used. The
implementation SHOULD return the offsets using the same timestamp
format as was used when the offsets were set.
以下に注意してください。 _現在のオフセット値を読む時間pps_getparams()を使用するアプリケーションは、どの形式が使用されているかを指定できません。 オフセットであるときにSHOULDが使用されていたように同じタイムスタンプ形式を使用するオフセットを返す実装は設定されました。
An application wishing to discover which mode bits it may set, with its current effective user ID, may call time_pps_getcap(). This function returns the set of mode bits that may be set by the application, without generating an EINVAL or EPERM error, for the specified PPS source. It does not return the current values for the mode bits. A call to time_pps_getcap() returns the mode bits corresponding to all supported timestamp formats.
それが現在の実効ユーザーIDと共にどのモードビットを設定するかもしれないかを発見したいアプリケーションは_呼び出し時間pps_getcap()がそうするかもしれません。 この機能はアプリケーションで設定されるかもしれないモードビットのセットを返します、EINVALかEPERMが誤りであると生成しない、指定されたPPSソースに。 それは現行価値をモードビット返しません。 _時間pps_getcap()までの呼び出しはタイムスタンプ形式であるとサポートされたすべてに対応するビットをモードに返します。
The time_pps_getcap() function MAY ignore the mode in which the associated UNIX file descriptor was opened, so the application might still receive an EBADF error on a call to time_pps_setparams(), even if time_pps_getcap() says that the chosen mode bits are allowed.
時間_pps_getcap()機能が関連UNIXファイルディスクリプタが開かれたモードを無視するかもしれないので、アプリケーションは_時間pps_setparams()までまだEBADF誤りを呼び出しに受けているかもしれません、時間_pps_getcap()が、選ばれたモードビットが許容されていると言っても。
The mode bits returned by time_pps_getcap() for distinct PPS handles may differ, reflecting the specific capabilities of the underlying hardware connection to the PPS source, or of the source itself.
異なったPPSのためのgetcap()が扱う時間_pps_によって返されたモードビットは異なるかもしれません、PPSソースとの基盤となるハードウェア接続、またはソース自体の特定の能力を反映して。
RETURN VALUES
リターン値
On successful completion, the time_pps_setparams(), time_pps_getparams(), and time_pps_getcap() functions return 0. Otherwise, a value of -1 is returned and errno is set to indicate the error.
無事終了のときに、時間_pps_setparams()、時間_pps_getparams()、および時間_pps_getcap()機能は0を返します。 さもなければ、-1の値を返します、そして、errnoは誤りを示すように用意ができています。
Mogul, et al. Informational [Page 15] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[15ページ]のRFC API行進
ERRORS
誤り
If the time_pps_setparams(), time_pps_getparams(), or time_pps_getcap() function fails, errno may be set to one of the following values:
時間_pps_setparams()、時間_pps_getparams()、または時間_pps_getcap()機能が失敗するなら、errnoは以下の値の1つに用意ができるかもしれません:
[EBADF] The handle parameter is not associated with a valid
file descriptor, or the descriptor is not open for
writing.
[EBADF] ハンドルパラメタが有効なファイルディスクリプタに関連づけられないか、または書くことにおいて、記述子は開いていません。
[EFAULT] A parameter points to an invalid address.
[EFAULT] パラメタは無効のアドレスを示します。
[EOPNOTSUPP] The use of the PPS API is not supported for the
associated file descriptor.
[EOPNOTSUPP] PPS APIの使用は関連ファイルディスクリプタのためにサポートされません。
[EINVAL] The operating system does not support all of the
requested mode bits.
[EINVAL] オペレーティングシステムは優に要求されたモードビットを支えません。
[EPERM] The process's effective user ID does not have the
required privileges to use the PPS API, or to set the
given mode bits.
[EPERM] 過程sの実効ユーザーIDには、PPS APIを使用するか、または与えられたモードビットを設定する必要な特権がありません。
3.4.3 New functions: access to PPS timestamps
3.4.3 新しい機能: PPSタイムスタンプへのアクセス
The API includes one function that gives applications access to PPS timestamps. As an implementation option, the application may request the API to block until the next timestamp is captured. (The API does not directly support the use of the select() or poll() system calls to wait for PPS events.)
APIはPPSタイムスタンプへのアプリケーションアクセスを与える1つの機能を含んでいます。 実装オプションとして、次のタイムスタンプが捕らわれるまで、アプリケーションはAPIをブロックまで要求するかもしれません。 (APIはPPSイベントを待つために直接選んだ()か投票()システムコールの使用をサポートしません。)
SYNOPSIS
構文
int time_pps_fetch(pps_handle_t handle,
const int tsformat,
pps_info_t *ppsinfobuf,
const struct timespec *timeout);
int時間_pps_フェッチ(pps_ハンドル_tハンドル、const int tsformat、pps_インフォメーション_t*ppsinfobuf、const struct timespec*タイムアウト)。
DESCRIPTION
記述
An application may use time_pps_fetch() to obtain the most recent timestamps captured for the PPS source specified by the handle parameter. The tsformat parameter specifies the desired timestamp format; if the requested timestamp format is not supported, the call fails and returns an error value. The application MUST specify exactly one timestamp format.
アプリケーションは、ハンドルパラメタによって指定されたPPSソースとして得られた最新のタイムスタンプを得るのに時間_pps_フェッチ()を使用するかもしれません。 tsformatパラメタは必要なタイムスタンプ形式を指定します。 要求されたタイムスタンプ形式がサポートされないなら、呼び出しは、誤り値に失敗して、返します。 アプリケーションはまさに1つのタイムスタンプ形式を指定しなければなりません。
Mogul, et al. Informational [Page 16] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[16ページ]のRFC API行進
This function blocks until either a timestamp is captured from the PPS source, or until the specified timeout duration has expired. If the timeout parameter is a NULL pointer, the function simply blocks until a timestamp is captured. If the timeout parameter specifies a delay of zero, the function returns immediately.
このタイムスタンプまでの機能ブロックは、PPSソースから得るか、または指定されたタイムアウト持続時間まで期限が切れました。 タイムアウトパラメタであるなら、タイムスタンプが捕らわれるまで、NULL指針、機能は単にブロックですか? タイムアウトパラメタがゼロの遅れを指定するなら、機能はすぐに、戻ります。
Support for blocking behavior is an implementation option. If the PPS_CANWAIT mode bit is clear, and the timeout parameter is either NULL or points to a non-zero value, the function returns an EOPNOTSUPP error. An application can discover whether the feature is implemented by using time_pps_getcap() to see if the PPS_CANWAIT mode bit is set.
振舞いを妨げるサポートは実装オプションです。 タイムアウトパラメタが非ゼロ値へのPPS_CANWAITモードビットが明確であり、NULLかポイントのどちらかであるなら、機能はEOPNOTSUPP誤りを返します。 アプリケーションは、特徴が_PPS_CANWAITモードビットが設定されるかどうかを見る時間pps_getcap()を使用することによって実装されるかどうか発見できます。
The result is stored in the ppsinfobuf parameter, whose fields are defined in section 3.2. If the function returns as the result of a timeout or error, the contents of the ppsinfobuf are undefined.
結果は分野がセクション3.2で定義されるppsinfobufパラメタに保存されます。 機能がタイムアウトか誤りの結果として戻るなら、ppsinfobufの内容は未定義です。
If this function is invoked before the system has captured a timestamp for the signal source, the ppsinfobuf returned will have its timestamp fields set to the time format's base date (e.g., for PPS_TSFMT_TSPEC, both the tv_sec and tv_nsec fields will be zero).
システムが信号ソースとしてタイムスタンプを得る前にこの機能が呼び出されると、返されたppsinfobufは時間形式のベース日付にタイムスタンプ分野を設定させるでしょう(tv_秒とtv_nsec分野の両方が例えば、PPS_TSFMT_TSPECに関する、ゼロになるでしょう)。
RETURN VALUES
リターン値
On successful completion, the time_pps_fetch() function returns 0. Otherwise, a value of -1 is returned and errno is set to indicate the error.
無事終了のときに、時間_pps_フェッチ()機能は0を返します。 さもなければ、-1の値を返します、そして、errnoは誤りを示すように用意ができています。
ERRORS
誤り
If the time_pps_fetch() function fails, errno may be set to one of the following values:
時間_pps_フェッチ()機能が失敗するなら、errnoは以下の値の1つに用意ができるかもしれません:
[EBADF] The handle parameter is not associated with a valid
file descriptor.
[EBADF] ハンドルパラメタは有効なファイルディスクリプタに関連づけられません。
[EFAULT] A parameter points to an invalid address.
[EFAULT] パラメタは無効のアドレスを示します。
[EINTR] A signal was delivered before the time limit
specified by the timeout parameter expired and before
a timestamp has been captured.
[EINTR] タイムアウトパラメタによって指定されたタイムリミットが期限が切れる前とタイムスタンプを得る前に信号を提供しました。
[EINVAL] The requested timestamp format is not supported.
[EINVAL] 要求されたタイムスタンプ形式はサポートされません。
[EOPNOTSUPP] The use of the PPS API is not supported for the
associated file descriptor.
[EOPNOTSUPP] PPS APIの使用は関連ファイルディスクリプタのためにサポートされません。
[ETIMEDOUT] The timeout duration has expired.
[ETIMEDOUT] タイムアウト持続時間は期限が切れました。
Mogul, et al. Informational [Page 17] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[17ページ]のRFC API行進
3.4.4 New functions: disciplining the kernel timebase
3.4.4 新しい機能: カーネルtimebaseを訓練します。
The API includes one OPTIONAL function to specify if and how a PPS source is provided to a kernel consumer of PPS events, such as the code used to discipline the operating system's internal timebase.
APIが指定するために1つのOPTIONAL機能を含んでいる、そして、オペレーティングシステムの内部のtimebaseを訓練するのに使用されるコードなどについてどうPPSイベントのカーネル消費者にPPSソースを提供するか。
SYNOPSIS
構文
int time_pps_kcbind(pps_handle_t handle,
const int kernel_consumer,
const int edge,
const int tsformat);
DESCRIPTION
_int時間pps_kcbind(pps_ハンドル_tハンドル、const intカーネル_消費者、const int縁、const int tsformat)。 記述
An application with appropriate privileges may use time_pps_kcbind() to bind a kernel consumer to the PPS source specified by the handle.
適切な特権があるアプリケーションは_カーネル消費者をハンドルによって指定されたPPSソースまで縛る時間pps_kcbind()を使用するかもしれません。
The kernel consumer is identified by the kernel_consumer parameter. In the current version of the API, the possible values for this parameter are:
カーネル消費者はカーネル_消費者パラメタによって特定されます。 APIの最新版では、このパラメタのための可能な値は以下の通りです。
#define PPS_KC_HARDPPS 0
#define PPS_KC_HARDPPS_PLL 1
#define PPS_KC_HARDPPS_FLL 2
#定義、PPS_KC_HARDPPS0#、が1#、が定義するPPS_KC_HARDPPS_PLLを定義する、PPS_KC_HARDPPS_FLL2
with these meanings:
これらの意味で:
PPS_KC_HARDPPS The kernel's hardpps() function (or equivalent).
PPS_KC_HARDPPS、カーネルのhardpps()機能(または、同等物)。
PPS_KC_HARDPPS_PLL
A variant of hardpps() constrained to use a
phase-locked loop.
hardpps()のHARDPPS_PLL A異形がフェーズロックドループを使用するのを抑制したPPS_KC_。
PPS_KC_HARDPPS_FLL
A variant of hardpps() constrained to use a
frequency-locked loop.
hardpps()のHARDPPS_FLL A異形が頻度で固定された輪を使用するのを抑制したPPS_KC_。
Implementation of any or all of these values is OPTIONAL.
いずれの実装かこれらの値のすべてがOPTIONALです。
The edge parameter indicates which edge of the PPS signal causes a timestamp to be delivered to the kernel consumer. It may have the value PPS_CAPTUREASSERT, PPS_CAPTURECLEAR, or PPS_CAPTUREBOTH, depending on particular characteristics of the PPS source. It may also be zero, which removes any binding between the PPS source and the kernel consumer.
縁のパラメタは、PPS信号のどの縁でカーネル消費者にタイムスタンプを提供するかを示します。 PPSソースの特定の特性によって、それは値のPPS_CAPTUREASSERT、PPS_CAPTURECLEAR、またはPPS_CAPTUREBOTHを持っているかもしれません。 また、それはゼロであるかもしれません。(そのゼロはPPSソースとカーネル消費者の間にどんな結合も移します)。
Mogul, et al. Informational [Page 18] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[18ページ]のRFC API行進
The tsformat parameter specifies the format for the timestamps delivered to the kernel consumer. If this value is zero, the implementation MAY choose the appropriate format, or return EINVAL. The implementation MAY ignore a non-zero value for this parameter.
tsformatパラメタはカーネル消費者に提供されたタイムスタンプに形式を指定します。 この値がゼロであるなら、実装は、適切な形式を選ぶか、またはEINVALを返すかもしれません。 実装はこのパラメタのために非ゼロ値を無視するかもしれません。
The binding created by this call persists until it is changed by a subsequent call specifying the same kernel_consumer. In particular, a subsequent call to time_pps_destroy() for the specified handle does not affect the binding.
この呼び出しで作成された結合は同じカーネル_消費者を指定するその後の呼び出しでそれを変えるまで持続しています。 特に、その後の_pps_が指定されたハンドルのための()を破壊する時までの呼び出しは結合に影響しません。
The binding is independent of any prior or subsequent changes to the PPS_CAPTUREASSERT and PPS_CAPTURECLEAR mode bits for the device. However, if either the edge or the tsformat parameter values are inconsistent with the capabilities of the PPS source, an error is returned. The implementation MAY also return an error if the tsformat value is unsupported for time_pps_kcbind(), even if it is supported for other uses of the API.
デバイスにおいて、結合はPPS_CAPTUREASSERTとPPS_CAPTURECLEARモードビットへのどんな先の、または、その後の変化からも独立しています。 しかしながら、縁かtsformatパラメタ値のどちらかがPPSソースの能力に反するなら、誤りは返されます。 また、tsformat値が_時間pps_kcbind()のときにサポートされないなら、実装は誤りを返すかもしれません、それがAPIの他の用途のためにサポートされても。
The operating system may enforce two restrictions on the bindings created by time_pps_kcbind():
オペレーティングシステムは2つの制限に_時間pps_kcbind()によって作成された結合に押しつけるかもしれません:
1. the kernel MAY return an error if an attempt is made to bind a
kernel consumer to more than one PPS source a time.
1. カーネル消費者のために1つ以上のPPSソースへの時間を縛るのを試みをするなら、カーネルは誤りを返すかもしれません。
2. the kernel MAY restrict the ability to set bindings to
processes with sufficient privileges to modify the system's
internal timebase. (On UNIX systems, such modification is
normally done using settimeofday() and/or adjtime(), and is
restricted to users with superuser privilege.)
2. カーネルはシステムの内部のtimebaseを変更できるくらいの特権でプロセスに結合を設定する能力を制限するかもしれません。 (そのような変更は、UNIXシステムの上では、通常、settimeofday()、そして/または、adjtime()を使用し終わって、「スーパー-ユーザ」特権でユーザに制限されます。)
Warning: If this feature is configured for a PPS source that does
not have an accurate 1-pulse-per-second signal, or is otherwise
inappropriately configured, use of this feature may result in
seriously incorrect timekeeping for the entire system. For best
results, the 1-PPS signal should have much better frequency
stability than the system's internal clock source (usually a
crystal-controlled oscillator), and should have jitter (variation
in interarrival time) much less than the system's clock-tick
interval.
警告: この特徴が正確な1二次信号あたり1パルスを持っていないPPSソースに構成されるか、または別の方法で不適当に構成されるなら、この特徴の使用は全体のシステムのための真剣に不正確な時間保持をもたらすかもしれません。 最も良い結果のために、1-PPS信号は、システムの内部クロックソース(通常水晶で制御された振動子)よりはるかに良い頻度の安定性を持つべきであり、システムの時計カチカチする音間隔よりはるかにジター(interarrival時間の変化)は持っているはずがありません。
See RFC 1589 [4] for more information about how the system's timebase may be disciplined using a PPS signal.
システムのtimebaseがPPS信号を使用することでどう訓練されるかもしれないかに関する詳しい情報のためのRFC1589[4]を見てください。
RETURN VALUES
リターン値
On successful completion, the time_pps_kcbind() function returns 0. Otherwise, a value of -1 is returned and errno is set to indicate the error.
無事終了のときに、時間_pps_kcbind()機能は0を返します。 さもなければ、-1の値を返します、そして、errnoは誤りを示すように用意ができています。
Mogul, et al. Informational [Page 19] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[19ページ]のRFC API行進
ERRORS
誤り
If the time_pps_kcbind() function fails, errno may be set to one of the following values:
時間_pps_kcbind()機能が失敗するなら、errnoは以下の値の1つに用意ができるかもしれません:
[EBADF] The handle parameter is not associated with a valid
file descriptor, or the descriptor is not open for
writing.
[EBADF] ハンドルパラメタが有効なファイルディスクリプタに関連づけられないか、または書くことにおいて、記述子は開いていません。
[EFAULT] A parameter points to an invalid address.
[EFAULT] パラメタは無効のアドレスを示します。
[EINVAL] The requested timestamp format is not supported.
[EINVAL] 要求されたタイムスタンプ形式はサポートされません。
[EOPNOTSUPP] The use of the PPS API is not supported for the
associated file descriptor, or this OPTIONAL
function is not supported.
[EOPNOTSUPP] PPS APIの使用が関連ファイルディスクリプタのためにサポートされないか、またはこのOPTIONAL機能はサポートされません。
[EPERM] The process's effective user ID does not have the
required privileges to set the binding.
[EPERM] 過程sの実効ユーザーIDには、結合を設定する必要な特権がありません。
3.5 Compliance rules
3.5 承諾規則
The key words "MUST", "MUST NOT", "REQUIRED","SHOULD", SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
「キーワード“MUST"、「必要であった」"SHOULD"がそうするべきでない「必須NOT」」、「5月」、このドキュメントで「任意」はRFC2119[1]で説明されるように解釈されることです。
Some features of this specification are OPTIONAL, but others are REQUIRED.
この仕様のいくつかの特徴がOPTIONALですが、他のものはREQUIREDです。
3.5.1 Functions
3.5.1 機能
An implementation MUST provide these functions:
実装はこれらの機能を提供しなければなりません:
- time_pps_create()
- time_pps_destroy()
- time_pps_setparams()
- time_pps_getparams()
- time_pps_getcap()
- time_pps_fetch()
- __()を作成してください--時間_pps_が()を破壊する時間_pps--_時間pps_setparams()--時間pps_getparams()--_時間pps_getcap()--時間_pps_フェッチ()
An implementation MUST provide this function, but it may be implemented as a function that always return an EOPNOTSUPP error, possibly on a per-source basis:
実装はこの機能を提供しなければなりませんが、機能がそんなにいつもEOPNOTSUPP誤りを返すとき、それは実装されるかもしれません、ことによると1ソースあたり1個のベースで:
- time_pps_kcbind()
- _時間pps_kcbind()
Mogul, et al. Informational [Page 20] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[20ページ]のRFC API行進
3.5.2 Mode bits
3.5.2 モードビット
An implementation MUST support at least one of these mode bits for each PPS source:
実装は少なくともこれらのモードビットの1つをそれぞれのPPSソースにサポートしなければなりません:
- PPS_CAPTUREASSERT
- PPS_CAPTURECLEAR
- PPS_CAPTUREASSERT--PPS_CAPTURECLEAR
and MAY support both of them. If an implementation supports both of these bits for a PPS source, it SHOULD allow them to be set simultaneously.
そして、それらの両方をサポートするかもしれません。 実装はこれらのビットを両方の、PPSソースに支えて、それはSHOULDです。彼らは同時に、設定させられてください。
An implementation MUST support this timestamp format:
実装は、このタイムスタンプが形式であるとサポートしなければなりません:
- PPS_TSFMT_TSPEC
- PPS_TSFMT_TSPEC
An implementation MAY support these mode bits:
実装はこれらのモードビットを支えるかもしれません:
- PPS_ECHOASSERT
- PPS_ECHOCLEAR
- PPS_OFFSETASSERT
- PPS_OFFSETCLEAR
- PPS_ECHOASSERT--PPS_ECHOCLEAR--PPS_OFFSETASSERT--PPS_OFFSETCLEAR
An implementation MAY support this timestamp format:
実装は、このタイムスタンプが形式であるとサポートするかもしれません:
- PPS_TSFMT_NTPFP
- PPS_TSFMT_NTPFP
3.6 Examples
3.6 例
A very simple use of this API might be:
このAPIの非常に簡単な使用は以下の通りです。
int fd;
pps_handle_t handle;
pps_params_t params;
pps_info_t infobuf;
struct timespec timeout;
int fd。 pps_ハンドル_tハンドル。 pps_params_t params。 _pps_インフォメーションt infobuf。 struct timespecタイムアウト。
/* Open a file descriptor and enable PPS on rising edges */
fd = open(PPSfilename, O_RDWR, 0);
time_pps_create(fd, &handle);
time_pps_getparams(handle, ¶ms);
if ((params.mode & PPS_CAPTUREASSERT) == 0) {
fprintf(stderr, "%s cannot currently CAPTUREASSERT\n",
PPSfilename);
exit(1);
}
/*は、立ち上がりエッジ*/fd=戸外(PPSfilename、O_RDWR、0)でファイルディスクリプタを開いて、PPSを有効にします。 時間_pps_は(fd、およびハンドル)を作成します。 _時間pps_getparams(ハンドル、¶ms)。 (PPS_CAPTUREASSERT) params.modeと=0)です。%sは現在、そうすることができません。「fprintf、(stderr、」、CAPTUREASSERT\n」、PPSfilename) ; (1)を出てください。
/* create a zero-valued timeout */
/*は無評価されたタイムアウト*/を作成します。
Mogul, et al. Informational [Page 21] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[21ページ]のRFC API行進
timeout.tv_sec = 0;
timeout.tv_nsec = 0;
timeout.tv_秒=0。 timeout.tv_nsec=0。
/* loop, printing the most recent timestamp every second or so */
while (1) {
sleep(1);
time_pps_fetch(handle, PPS_TSFMT_TSPEC, &infobuf, &timeout);
printf("Assert timestamp: %d.%09d, sequence: %ld\n",
infobuf.assert_timestamp.tv_sec,
infobuf.assert_timestamp.tv_nsec,
infobuf.assert_sequence);
}
/*は輪にされて、(1)である間、印刷している最新のタイムスタンプはあらゆる*のおよそ2番目の/です。睡眠(1); 時間_pps_は(ハンドル、PPS_TSFMT_TSPEC、およびinfobuf、およびタイムアウト)をとって来ます; printf(「タイムスタンプ: %d.%09d、系列: %ldが\nであると断言してください」、infobuf.assert_timestamp.tv_秒、infobuf.assert_timestamp.tv_nsec、infobuf.assert_系列)
Note that this example omits most of the error-checking that would be expected in a reliable program.
この例が高信頼のプログラムで予想される誤り照合の大部分を省略することに注意してください。
Also note that, on a system that supports PPS_CANWAIT, the function of these lines:
また、これらの機能がPPS_がCANWAITであるとサポートするシステムの上に立ち並ぶことに注意してください:
sleep(1);
time_pps_fetch(handle, PPS_TSFMT_TSPEC, &infobuf, &timeout);
睡眠(1)。 時間_pps_フェッチ(ハンドル、PPS_TSFMT_TSPEC、およびinfobuf、およびタイムアウト)。
might be more reliably accomplished using:
より確かに優れた使用であるかもしれません:
timeout.tv_sec = 100;
timeout.tv_nsec = 0;
time_pps_fetch(handle, PPS_TSFMT_TSPEC, &infobuf, &timeout);
timeout.tv_秒=100。 timeout.tv_nsec=0。 時間_pps_フェッチ(ハンドル、PPS_TSFMT_TSPEC、およびinfobuf、およびタイムアウト)。
The (arbitrary) timeout value is used to protect against the possibility that another application might disable PPS timestamps, or that the hardware generating the timestamps might fail.
(任意)のタイムアウト値は、別のアプリケーションが、PPSがタイムスタンプであることを損傷するかもしれないか、またはタイムスタンプを生成するハードウェアが失敗するかもしれない可能性から守るのに使用されます。
A slightly more elaborate use of this API might be:
このAPIのわずかに入念な使用は以下の通りです。
int fd;
pps_handle_t handle;
pps_params_t params;
pps_info_t infobuf;
int avail_mode;
struct timespec timeout;
int fd。 pps_ハンドル_tハンドル。 pps_params_t params。 _pps_インフォメーションt infobuf。 int利益_モード。 struct timespecタイムアウト。
/* Open a file descriptor */
fd = open(PPSfilename, O_RDWR, 0);
time_pps_create(fd, &handle);
/*はファイルディスクリプタ*/fd=戸外(PPSfilename、O_RDWR、0)を開きます。 時間_pps_は(fd、およびハンドル)を作成します。
/*
* Find out what features are supported
*/
/**は、どんな特徴が*/であるとサポートされるかを見つけます。
Mogul, et al. Informational [Page 22] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[22ページ]のRFC API行進
time_pps_getcap(handle, &avail_mode);
if ((avail_mode & PPS_CAPTUREASSERT) == 0) {
fprintf(stderr, "%s cannot CAPTUREASSERT\n", PPSfilename);
exit(1);
}
if ((avail_mode & PPS_OFFSETASSERT) == 0) {
fprintf(stderr, "%s cannot OFFSETASSERT\n", PPSfilename);
exit(1);
}
_時間pps_getcap(_モードを扱って、役に立ちます)。 %sはそうすることができません。「((利益_モードとPPS_CAPTUREASSERT)=0)である、fprintf、(stderr、」、CAPTUREASSERT\n」、PPSfilename) ; (1)を出てください;、((利益_モードとPPS_OFFSETASSERT)=0)です。%sはそうすることができません。「fprintf、(stderr、」、OFFSETASSERT\n」、PPSfilename) ; (1)を出てください。
/*
* Capture assert timestamps, and
* compensate for a 675 nsec propagation delay
*/
/**捕獲は、タイムスタンプ、および*が675nsec伝播遅延*/を補うと断言します。
time_pps_getparams(handle, ¶ms);
params.assert_offset.tv_sec = 0;
params.assert_offset.tv_nsec = 675;
params.mode |= PPS_CAPTUREASSERT | PPS_OFFSETASSERT;
time_pps_setparams(handle, ¶ms);
_時間pps_getparams(ハンドル、¶ms)。 params.assert_offset.tv_秒=0。 params.assert_offset.tv_nsec=675。 params.mode|= PPS_CAPTUREASSERT| PPS_OFFSETASSERT。 _時間pps_setparams(ハンドル、¶ms)。
/* create a zero-valued timeout */
timeout.tv_sec = 0;
timeout.tv_nsec = 0;
/*は無評価されたタイムアウト*/timeout.tv_秒=0を作成します。 timeout.tv_nsec=0。
/* loop, printing the most recent timestamp every second or so */
while (1) {
if (avail_mode & PPS_CANWAIT) {
time_pps_fetch(handle, PPS_TSFMT_TSPEC, &infobuf, NULL);
/* waits for the next event */
} else {
sleep(1);
time_pps_fetch(handle, PPS_TSFMT_TSPEC, &infobuf,
timeout);
/*輪、最新のタイムスタンプを印刷して、あらゆるおよそ2番目の*/が(1)をゆったり過ごす、(利益_モードとPPS_CANWAIT)がほかに_pps_フェッチ(ハンドル、PPS_TSFMT_TSPEC、およびinfobuf、NULL); 次のイベント*/のための/*待ちを調節する、睡眠(1)(時間_pps_フェッチ(ハンドル、PPS_TSFMT_TSPEC、およびinfobuf、タイムアウト))
}
printf("Assert timestamp: %d.%09d, sequence: %ld\n",
infobuf.assert_timestamp.tv_sec,
infobuf.assert_timestamp.tv_nsec,
infobuf.assert_sequence);
}
printf(「タイムスタンプ: %d.が%09d、系列であると断言してください: %は\nをldする」infobuf.assert_timestamp.tv_秒、infobuf.assert_timestamp.tv_nsec、infobuf.assert_系列)。 }
Again, most of the necessary error-checking has been omitted from this example.
一方、必要な誤り照合の大部分はこの例から省略されました。
Mogul, et al. Informational [Page 23] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[23ページ]のRFC API行進
4 Security Considerations
4 セキュリティ問題
This API gives applications three capabilities:
このAPIは3つの能力をアプリケーションに与えます:
- Causing the system to capture timestamps on certain events.
- システムが、あるイベントに関するタイムスタンプを得ることを引き起こします。
- Obtaining timestamps for certain events.
- あるイベントのためのタイムスタンプを得ます。
- Affecting the system's internal timebase.
- システムの内部のtimebaseに影響します。
The first capability should not affect security directly, but might cause a slight increase in interrupt latency and interrupt-handling overhead.
最初の能力は、直接セキュリティに影響するべきではありませんが、中断潜在と割込み処理オーバーヘッドのわずかな増加を引き起こすかもしれません。
The second capability might be useful in implementing certain kinds of covert communication channels.
2番目の能力はある種類のひそかな通信チャネルを実装する際に役に立つかもしれません。
In most cases, neither of these first two issues is a significant security threat, because the traditional UNIX file protection facility may be used to to limit access to the relevant special files. Provision of the PPS API adds minimal additional risk.
多くの場合、これらの最初の2冊のどちらも重要な軍事的脅威ではありません、施設がアクセスを制限するのに使用されているかもしれない伝統的なUNIXファイル保護が関連特別番組にファイルされるので。 PPS APIの設備は最小量の追加危険を加えます。
The final capability is reserved to highly privileged users. In UNIX systems, this means those with superuser privilege. Such users can evade protections based on file permissions; however, such users can in general cause unbounded havoc, and can set the internal timebase (and its rate of change), so this API creates no new vulnerabilities.
最終的な能力は非常に特権があるユーザに予約されます。 UNIXシステムでは、これは「スーパー-ユーザ」特権があるそれらを意味します。 そのようなユーザはファイル許容に基づく保護を回避できます。 しかしながら、そのようなユーザが一般に、限りない大破壊を引き起こす場合があって、内部のtimebase(そして、増減率)を設定できるので、このAPIはどんな新しい脆弱性も作成しません。
5 Acknowledgements
5つの承認
The API in this document draws some of its inspiration from the LBL "ppsclock" distribution [2], originally implemented in 1993 by Steve McCanne, Craig Leres, and Van Jacobson. We also thank Poul-Henning Kamp, Craig Leres, Judah Levine, and Harlan Stenn for helpful comments they contributed during the drafting of this document.
APIは1993年に元々スティーブMcCanne、クレイグLeres、およびヴァン・ジェーコブソンによって実装されたLBL"ppsclock"分配[2]からインスピレーションのいくつかを本書では得ます。 また、私たちは、それらがこのドキュメントの草稿の間、貢献したのを役に立つコメントのためのポール-ヘニング・カンプ、クレイグLeres、ユダ・レヴィン、およびハーランStennに感謝します。
Mogul, et al. Informational [Page 24] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[24ページ]のRFC API行進
6 References
6つの参照箇所
1. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
1. ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
2. Steve McCanne, Craig Leres, and Van Jacobson. PPSCLOCK.
ftp://ftp.ee.lbl.gov/ppsclock.tar.Z.
2. スティーブMcCanne、クレイグLeres、およびバンジェーコブソン。 PPSCLOCK ftp://ftp.ee.lbl.gov/ppsclock.tar.Z 。
3. Mills, D., "Network Time Protocol (Version 3): Specification,
Implementation and Analysis", RFC 1305, March 1992.
3. 工場、D.、「ネットワーク時間は以下について議定書の中で述べ(バージョン3)」。 「仕様、実装、および分析」(RFC1305)は1992を行進させます。
4. Mills, D., "A Kernel Model for Precision Timekeeping", RFC 1589,
March, 1994.
4. 工場、D.、「精度時間保持のためのカーネルモデル」、RFC1589、1994年3月。
5. The Open Group. The Single UNIX Specification, Version 2 - 6 Vol
Set for UNIX 98. Document number T912, The Open Group, February,
1997.
5. TheOpenGroup。 ただ一つのUNIX仕様、2--6VolがUNIX98に設定するバージョン。 1997年2月に数のT912、TheOpenGroupを記録してください。
Mogul, et al. Informational [Page 25] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[25ページ]のRFC API行進
7 Authors' Addresses
7人の作者のアドレス
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, U.S.A.
Avenueパロアルト、ジェフリー・C.の要人の西洋の研究所コンパックコンピュータ社250の大学カリフォルニア 94305、米国
Phone: 1 650 617 3304 (email preferred) EMail: mogul@wrl.dec.com
以下に電話をしてください。 1 650 617 3304(好まれたメール)EMail: mogul@wrl.dec.com
David L. Mills Electrical and Computer Engineering Department University of Delaware Newark, DE 19716
デヴィッドL.は電気とComputer技術部デラウエア大学ニューアーク、DE 19716を製粉します。
Phone: (302) 831-8247 EMail: mills@udel.edu
以下に電話をしてください。 (302) 831-8247 メールしてください: mills@udel.edu
Jan Brittenson Sun Microsystems, Inc. 901 San Antonio Rd M/S MPK17-202 Palo Alto, CA 94303 Email: Jan.Brittenson@Eng.Sun.COM
1月のBrittensonサン・マイクロシステムズ・インク901サンアントニオM/S MPK17-202第パロアルト、カリフォルニア 94303はメールされます: Jan.Brittenson@Eng.Sun.COM
Jonathan Stone Stanford Distributed Systems Group Stanford, CA 94305
ジョナサンストーンスタンフォードDistributed Systemsはスタンフォード、カリフォルニア 94305を分類します。
Phone: (650) 723-2513 EMail: jonathan@dsg.stanford.edu
以下に電話をしてください。 (650) 723-2513 メールしてください: jonathan@dsg.stanford.edu
Ulrich Windl Universitaet Regensburg, Klinikum
ユーリッヒ・Windl Universitaetレーゲンスブルク、Klinikum
EMail: ulrich.windl@rz.uni-regensburg.de
メール: ulrich.windl@rz.uni-regensburg.de
Mogul, et al. Informational [Page 26] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[26ページ]のRFC API行進
A. Extensions and related APIs
A。 拡大と関連するAPI
The API specified in the main body of this document could be more useful with the provision of several extensions or companion APIs.
このドキュメントの本体で指定されたAPIはいくつかの拡大か仲間APIの支給によって、より役に立つかもしれません。
At present, the interfaces listed in this appendix are not part of the formal specification in this document.
現在のところ、この付録に記載されたインタフェースは本書では形式仕様の一部ではありません。
A.1 Extension: Parameters for the "echo" mechanism
A.1拡張子: 「エコー」メカニズムのためのパラメタ
The "echo" mechanism described in the body of this specification leaves most of the details to the implementor, especially the designation of one or more output pins.
この仕様のボディーで説明された「エコー」メカニズムは作成者(特に1本以上の出力ピンの名称)に詳細の大部分を出発します。
It might be useful to extend this API to provide either or both of these features:
これらの特徴のどちらかか両方を提供するためにこのAPIを広げるのは役に立つかもしれません:
- A means by which the application can discover which output
pin is echoing the input pin.
- アプリケーションがどの出力ピンを発見できる手段は入力ピンを反響することです。
- A means by which the application can select which output
pin is echoing the input pin.
- アプリケーションがどの出力ピンを選択できる手段は入力ピンを反響することです。
A.2 Extension: Obtaining information about external clocks
A.2拡張子: 外部クロックに関する獲得情報
The PPS API may be useful with a wide variety of reference clocks, connected via several different interface technologies (including serial lines, parallel interfaces, and bus-level interfaces). These reference clocks can have many features and parameters, some of which might not even have been invented yet.
PPS APIはさまざまな基準クロックによって役に立つかもしれません、いくつかの異なったインタフェース技術で、接続されています(シリアル・ライン、並列インターフェース、およびバスレベルインタフェースを含んでいて)。 これらの基準クロックは多くの特徴とパラメタを持つことができます。その或るものはまだ発明されてさえいないかもしれません。
We believe that it would be useful to have a mechanism by which an application can discover arbitrary features and parameters of a reference clock. These might include:
私たちは、アプリケーションが基準クロックの任意の特徴とパラメタを発見できるメカニズムを持っているのが役に立つと信じています。 これらは以下を含むかもしれません。
- Clock manufacturer, model number, and revision level
- Whether the clock is synchronized to an absolute standard
- For synchronized clocks,
* The specific standard
* The accuracy of the standard
* The path used (direct connection, shortwave, longwave,
satellite, etc.)
* The distance (offset) and variability of this path
- 時計メーカー、型番、および改正レベル--時計が連動している時計の絶対規格に連動するか否かに関係なく、*である、特定の規格*、経路が使用した規格*(ダイレクト接続、短波、longwave、衛星など)の精度 * この経路の距離(相殺する)と可変性
Mogul, et al. Informational [Page 27] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[27ページ]のRFC API行進
- For PPS sources,
* The pulse rate
* The pulse shape
* Which edge of the pulse corresponds to the epoch
- *PPSソースに、パルスは、*がパルスのそれの縁が時代に対応するパルス波形*であると評定します。
- The time representation format
- 時間表現形式
This information might best be provided by an API analogous to the standard "curses" API, with a database analogous to the standard "terminfo" database. That is, a "clockinfo" database would contain a set of (attribute, value) pairs for each type of clock, and the API would provide a means to query this database.
標準の「呪い」APIへの類似のAPIでこの情報を最もよく提供するかもしれません、標準の"terminfo"データベースへの類似のデータベースで。 すなわち、"clockinfo"データベースはそれぞれのタイプの時計のための1セットの(属性、値)組を含んでいるでしょう、そして、APIはこのデータベースについて質問する手段を提供するでしょう。
Additional mechanisms would allow an application to discover the clock or clocks connected to the local system, and to discover the clockinfo type of a specific clock device.
追加メカニズムで、アプリケーションは、ローカルシステムに接続された時計か時計を発見して、特定の時計デバイスのclockinfoタイプを発見するでしょう。
A.3 Extension: Finding a PPS source
A.3拡張子: PPSソースを見つけます。
Although the clockinfo database described in section A.2, together with the discover mechanisms described there, would allow an application to discover the PPS source (or sources) connected to a system, it might be more complex than necessary.
clockinfoデータベースがセクションでA.2について説明しましたが、複雑である、そこで説明されたメカニズムを発見してください、とシステムに接続されたPPSソース(または、ソース)を発見するアプリケーションが許容して、それは必要とするより複雑であるかもしれません。
A simpler approach would be to support a single function that provides the identity of one or more PPS sources.
より簡単なアプローチは1つ以上のPPSソースのアイデンティティを提供するただ一つの機能をサポートするだろうことです。
For example, the function might be declared as
例えば、機能として、宣言されるかもしれません。
int time_pps_findsource(int index,
char *path, int pathlen,
char *idstring, int idlen);
_int時間pps_findsource(intインデックス、炭*経路、int pathlenは*idstring、int idlenを炭にします)。
The index argument implicitly sets up an ordering on the PPS sources attached to the system. An application would use this function to inquire about the Nth source. The function would return -1 if no such source exists; otherwise, it would return 0, and would place the pathname of the associated special file in the path argument. It would also place an identification string in the idstring argument. The identification string could include the clock make, model, version, etc., which could then be used by the application to control its behavior.
インデックス議論はそれとなくシステムに取り付けられたPPSソースに注文をセットアップします。 アプリケーションは、Nthソースについて問い合わせをするのにこの機能を使用するでしょう。 何かそのようなソースが存在していないなら、機能は-1を返すでしょう。 さもなければ、それは、0を返して、関連特別なファイルのパス名を経路議論に置くでしょう。 また、それは識別ストリングをidstring議論に置くでしょう。 識別ストリングは時計造、モデル、バージョンなどを含むかもしれません。(次に、振舞いを制御するのにアプリケーションでそれを使用できるでしょう)。
This function might simply read the Nth line from a simple database, containing lines such as:
以下などの系列を含んでいて、この機能は簡単なデータベースからNth系列を単に読むかもしれません。
/dev/tty00 "TrueTime 468-DC"
/dev/pps1 "Homebrew rubidium frequency standard"
/dev/tty00、「TrueTime、468DC、」 /dev/pps1「Homebrewルビジウム頻度規格」
Mogul, et al. Informational [Page 28] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[28ページ]のRFC API行進
allowing the system administrator to describe the configuration of PPS sources.
システム管理者がPPSソースの構成について説明するのを許容します。
B. Example implementation: PPSDISC Line discipline
B。 例の実装: PPSDISC線規律
One possible implementation of the PPS API might be to define a new "line discipline" and then map the API onto a set of ioctl() commands. Here we sketch such an implementation; note that this is not part of the specification of the API, and applications should not expect this low-level interface to be available.
PPS APIの1つの可能な実装は、新しい「系列規律」を定義して、次に、1セットのioctl()コマンドにAPIを写像することであるかもしれません。 ここに、私たちはそのような実装についてスケッチします。 これがAPIの仕様の一部でないことに注意してください。そうすれば、アプリケーションは、この低レベルであるインタフェースが利用可能であると予想するべきではありません。
In this approach, the set of line disciplines is augmented with one new line discipline, PPSDISC. This discipline will act exactly the same as the TTYDISC discipline, except for its handling of modem DCD interrupts.
PPSDISC、このアプローチでは、系列規律のセットは1つの復帰改行規律で増大します。 この規律はまさにモデムDCD割込みの取り扱い以外のTTYDISC規律と同じに行動するでしょう。
Once the TIOCSETD ioctl() has been used to select this line discipline, PPS-related operations on the serial line may be invoked using new ioctl() commands. For example (values used only for illustration):
TIOCSETD ioctl()がこの系列規律を選択するのにいったん使用されると、シリアル・ラインにおけるPPS関連の操作は、新しいioctl()コマンドを使用することで呼び出されるかもしれません。 例えば、(イラストにだけ使用される値):
#define PPSFETCH _IOR('t', 75, pps_info_t)
#define PPSSETPARAM _IOW('t', 76, pps_params_t)
#define PPSGETPARAM _IOR('t', 77, pps_params_t)
#define PPSGETCAP _IOR('t', 78, int)
#PPSFETCH_IOR('t'を定義してください、そして、75、pps_インフォメーション_t)#はPPSSETPARAM_IOW('t'を定義して、76、pps_params_t)#はPPSGETPARAM_IOR('t'を定義して、77、pps_params_t)#はPPSGETCAP_IORを定義します。('t'、78、int)
B.1 Example
B.1の例
A typical use might be:
典型的な使用は以下の通りです。
int ldisc = PPSDISC;
pps_params_t params;
pps_info_t infobuf;
int ldiscはPPSDISCと等しいです。 pps_params_t params。 _pps_インフォメーションt infobuf。
ioctl(fd, TIOCSETD, &ldisc); /* set discipline */
ioctl(fd、TIOCSETD、およびldisc)。 /*セット規律*/
/*
* Check the capabilities of this PPS source to see
* if it supports what we need.
*/
ioctl(fd, PPSGETCAP, ¶ms);
if ((params.mode & PPS_CAPTUREASSERT) == 0) {
fprintf(stderr, "PPS source is not suitable\n");
exit(1);
}
*私たちが必要とするものをサポートするなら、/**はこのPPSソースが見る能力をチェックします。 */ioctl(fd、PPSGETCAP、¶ms)。 (PPS_CAPTUREASSERT) params.modeと=0)です。fprintf(stderr、「PPSソースは適当な\nでない」)(出口(1))
/*
* Set this line to timestamp on a rising-edge interrupt
/**は立ち上がりエッジ中断のときにこの系列をタイムスタンプに設定しました。
Mogul, et al. Informational [Page 29] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[29ページ]のRFC API行進
*/
ioctl(fd, PPSGETPARAMS, ¶ms);
params.mode |= PPS_CAPTUREASSERT;
ioctl(fd, PPSSETPARAMS, ¶ms);
*/ioctl(fd、PPSGETPARAMS、¶ms)。 params.mode|= PPS_CAPTUREASSERT。 ioctl(fd、PPSSETPARAMS、¶ms)。
sleep(2); /* allow time for the PPS pulse to happen */
睡眠(2)。 /*がPPSパルスが起こる時間を許容する、*/
/* obtain most recent timestamp and sequence # for this line */
ioctl(fd, PPSFETCH, &infobuf);
/*はこの線*/ioctl(fd、PPSFETCH、およびinfobuf)に最新のタイムスタンプと系列#を得ます。
Again, this example imprudently omits any error-checking.
一方、この例は無躾にどんな誤り照合も省略します。
C. Available implementations
C。 利用可能な実現
Several available implementations of this API are listed at <http://www.ntp.org/ppsapi/PPSImpList.html>. Note that not all of these implementations correspond to the current version of the specification.
このAPIのいくつかの利用可能な実現が<http://www.ntp.org/ppsapi/PPSImpList.html>に記載されています。 これらの実現のすべてが仕様の最新版に対応するというわけではないことに注意してください。
Mogul, et al. Informational [Page 30] RFC 2783 Pulse-Per-Second API March 2000
ムガール人、他 2000年の2783年の1秒あたりのパルスの情報[30ページ]のRFC API行進
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Mogul, et al. Informational [Page 31]
ムガール人、他 情報[31ページ]
一覧
スポンサーリンク
