요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
================================================
PLIP: The Parallel Line Internet Protocol Device
================================================
Donald Becker ([email protected])
I.D.A. Supercomputing Research Center, Bowie MD 20715
At some point T. Thorn will probably contribute text,
Tommy Thorn ([email protected])
PLIP Introduction
-----------------
This document describes the parallel port packet pusher for Net/LGX.
This device interface allows a point-to-point connection between two
parallel ports to appear as a IP network interface.
What is PLIP?
=============
PLIP is Parallel Line IP, that is, the transportation of IP packages
over a parallel port. In the case of a PC, the obvious choice is the
printer port. PLIP is a non-standard, but [can use] uses the standard
LapLink null-printer cable [can also work in turbo mode, with a PLIP
cable]. [The protocol used to pack IP packages, is a simple one
initiated by Crynwr.]
Advantages of PLIP
==================
It's cheap, it's available everywhere, and it's easy.
The PLIP cable is all that's needed to connect two Linux boxes, and it
can be built for very few bucks.
Connecting two Linux boxes takes only a second's decision and a few
minutes' work, no need to search for a [supported] netcard. This might
even be especially important in the case of notebooks, where netcards
are not easily available.
Not requiring a netcard also means that apart from connecting the
cables, everything else is software configuration [which in principle
could be made very easy.]
Disadvantages of PLIP
=====================
Doesn't work over a modem, like SLIP and PPP. Limited range, 15 m.
Can only be used to connect three (?) Linux boxes. Doesn't connect to
an existing Ethernet. Isn't standard (not even de facto standard, like
SLIP).
Performance
===========
PLIP easily outperforms Ethernet cards....(ups, I was dreaming, but
it *is* getting late. EOB)
PLIP driver details
-------------------
The Linux PLIP driver is an implementation of the original Crynwr protocol,
that uses the parallel port subsystem of the kernel in order to properly
share parallel ports between PLIP and other services.
IRQs and trigger timeouts
=========================
When a parallel port used for a PLIP driver has an IRQ configured to it, the
PLIP driver is signaled whenever data is sent to it via the cable, such that
when no data is available, the driver isn't being used.
However, on some machines it is hard, if not impossible, to configure an IRQ
to a certain parallel port, mainly because it is used by some other device.
On these machines, the PLIP driver can be used in IRQ-less mode, where
the PLIP driver would constantly poll the parallel port for data waiting,
and if such data is available, process it. This mode is less efficient than
the IRQ mode, because the driver has to check the parallel port many times
per second, even when no data at all is sent. Some rough measurements
indicate that there isn't a noticeable performance drop when using IRQ-less
mode as compared to IRQ mode as far as the data transfer speed is involved.
There is a performance drop on the machine hosting the driver.
When the PLIP driver is used in IRQ mode, the timeout used for triggering a
data transfer (the maximal time the PLIP driver would allow the other side
before announcing a timeout, when trying to handshake a transfer of some
data) is, by default, 500usec. As IRQ delivery is more or less immediate,
this timeout is quite sufficient.
When in IRQ-less mode, the PLIP driver polls the parallel port HZ times
per second (where HZ is typically 100 on most platforms, and 1024 on an
Alpha, as of this writing). Between two such polls, there are 10^6/HZ usecs.
On an i386, for example, 10^6/100 = 10000usec. It is easy to see that it is
quite possible for the trigger timeout to expire between two such polls, as
the timeout is only 500usec long. As a result, it is required to change the
trigger timeout on the *other* side of a PLIP connection, to about
10^6/HZ usecs. If both sides of a PLIP connection are used in IRQ-less mode,
this timeout is required on both sides.
It appears that in practice, the trigger timeout can be shorter than in the
above calculation. It isn't an important issue, unless the wire is faulty,
in which case a long timeout would stall the machine when, for whatever
reason, bits are dropped.
A utility that can perform this change in Linux is plipconfig, which is part
of the net-tools package (its location can be found in the
Documentation/Changes file). An example command would be
'plipconfig plipX trigger 10000', where plipX is the appropriate
PLIP device.
PLIP hardware interconnection
-----------------------------
PLIP uses several different data transfer methods. The first (and the
only one implemented in the early version of the code) uses a standard
printer "null" cable to transfer data four bits at a time using
data bit outputs connected to status bit inputs.
The second data transfer method relies on both machines having
bi-directional parallel ports, rather than output-only ``printer``
ports. This allows byte-wide transfers and avoids reconstructing
nibbles into bytes, leading to much faster transfers.
Parallel Transfer Mode 0 Cable
==============================
The cable for the first transfer mode is a standard
printer "null" cable which transfers data four bits at a time using
data bit outputs of the first port (machine T) connected to the
status bit inputs of the second port (machine R). There are five
status inputs, and they are used as four data inputs and a clock (data
strobe) input, arranged so that the data input bits appear as contiguous
bits with standard status register implementation.
A cable that implements this protocol is available commercially as a
"Null Printer" or "Turbo Laplink" cable. It can be constructed with
two DB-25 male connectors symmetrically connected as follows::
STROBE output 1*
D0->ERROR 2 - 15 15 - 2
D1->SLCT 3 - 13 13 - 3
D2->PAPOUT 4 - 12 12 - 4
D3->ACK 5 - 10 10 - 5
D4->BUSY 6 - 11 11 - 6
D5,D6,D7 are 7*, 8*, 9*
AUTOFD output 14*
INIT output 16*
SLCTIN 17 - 17
extra grounds are 18*,19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Do not connect these pins on either end
If the cable you are using has a metallic shield it should be
connected to the metallic DB-25 shell at one end only.
Parallel Transfer Mode 1
========================
The second data transfer method relies on both machines having
bi-directional parallel ports, rather than output-only ``printer``
ports. This allows byte-wide transfers, and avoids reconstructing
nibbles into bytes. This cable should not be used on unidirectional
``printer`` (as opposed to ``parallel``) ports or when the machine
isn't configured for PLIP, as it will result in output driver
conflicts and the (unlikely) possibility of damage.
The cable for this transfer mode should be constructed as follows::
STROBE->BUSY 1 - 11
D0->D0 2 - 2
D1->D1 3 - 3
D2->D2 4 - 4
D3->D3 5 - 5
D4->D4 6 - 6
D5->D5 7 - 7
D6->D6 8 - 8
D7->D7 9 - 9
INIT -> ACK 16 - 10
AUTOFD->PAPOUT 14 - 12
SLCT->SLCTIN 13 - 17
GND->ERROR 18 - 15
extra grounds are 19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Do not connect these pins on either end
Once again, if the cable you are using has a metallic shield it should
be connected to the metallic DB-25 shell at one end only.
PLIP Mode 0 transfer protocol
=============================
The PLIP driver is compatible with the "Crynwr" parallel port transfer
standard in Mode 0. That standard specifies the following protocol::
send header nibble '0x8'
count-low octet
count-high octet
... data octets
checksum octet
Each octet is sent as::
<wait for rx. '0x1?'> <send 0x10+(octet&0x0F)>
<wait for rx. '0x0?'> <send 0x00+((octet>>4)&0x0F)>
To start a transfer the transmitting machine outputs a nibble 0x08.
That raises the ACK line, triggering an interrupt in the receiving
machine. The receiving machine disables interrupts and raises its own ACK
line.
Restated::
(OUT is bit 0-4, OUT.j is bit j from OUT. IN likewise)
Send_Byte:
OUT := low nibble, OUT.4 := 1
WAIT FOR IN.4 = 1
OUT := high nibble, OUT.4 := 0
WAIT FOR IN.4 = 0
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
PLIP의 개념과 장단점
1-60이 문서는 Donald Becker가 작성한 Net/LGX용 parallel-port packet 전송 장치를 설명합니다. 두 parallel port 사이의 point-to-point 연결을 IP network interface처럼 보이게 하는 device interface입니다. T. Thorn 또는 Tommy Thorn이 추후 text를 기여할 수 있다는 초기 문서 메모도 포함되어 있습니다.
PLIP는 Parallel Line IP, 즉 parallel port를 통한 IP packet 전송입니다. PC에서는 보통 printer port를 사용합니다. 표준 protocol은 아니지만 표준 LapLink null-printer cable을 사용할 수 있고, 전용 PLIP cable에서는 turbo mode도 가능합니다. 원문의 대괄호 안에는 Crynwr가 시작한 단순한 packet 포장 protocol이라는 편집 중 설명이 남아 있으며 원문 영역에 그대로 보존됩니다.
장점은 저렴하고 어디서나 구하기 쉬우며 구성이 간단하다는 것입니다. PLIP cable 하나만 있으면 Linux machine 두 대를 매우 적은 비용으로 연결할 수 있습니다. 지원 network card를 찾지 않아도 빠르게 연결할 수 있어 network card 확보가 어려운 notebook에서 특히 유용할 수 있습니다. Cable 연결 외에는 거의 모두 software 설정입니다.
단점은 SLIP·PPP처럼 modem을 통과하지 못하고 거리가 약 15m로 제한된다는 점입니다. 연결 가능한 Linux machine 수가 제한적이고 기존 Ethernet에 직접 연결되지 않으며, 사실상의 표준인 SLIP과 달리 PLIP는 표준도 아닙니다.
Performance 절의 'Ethernet card를 쉽게 능가한다'는 문장은 곧바로 늦은 시간에 꾼 꿈이었다는 농담으로 철회됩니다. 실제 성능 주장으로 해석해서는 안 됩니다.
Parallel port 기반 point-to-point IP의 장단점입니다.
.. SPDX-License-Identifier: GPL-2.0
================================================
PLIP: The Parallel Line Internet Protocol Device
================================================
Donald Becker ([email protected])
I.D.A. Supercomputing Research Center, Bowie MD 20715
At some point T. Thorn will probably contribute text,
Tommy Thorn ([email protected])
PLIP Introduction
-----------------
This document describes the parallel port packet pusher for Net/LGX.
This device interface allows a point-to-point connection between two
parallel ports to appear as a IP network interface.
What is PLIP?
=============
PLIP is Parallel Line IP, that is, the transportation of IP packages
over a parallel port. In the case of a PC, the obvious choice is the
printer port. PLIP is a non-standard, but [can use] uses the standard
LapLink null-printer cable [can also work in turbo mode, with a PLIP
cable]. [The protocol used to pack IP packages, is a simple one
initiated by Crynwr.]
Advantages of PLIP
==================
It's cheap, it's available everywhere, and it's easy.
The PLIP cable is all that's needed to connect two Linux boxes, and it
can be built for very few bucks.
Connecting two Linux boxes takes only a second's decision and a few
minutes' work, no need to search for a [supported] netcard. This might
even be especially important in the case of notebooks, where netcards
are not easily available.
Not requiring a netcard also means that apart from connecting the
cables, everything else is software configuration [which in principle
could be made very easy.]
Disadvantages of PLIP
=====================
Doesn't work over a modem, like SLIP and PPP. Limited range, 15 m.
Can only be used to connect three (?) Linux boxes. Doesn't connect to
an existing Ethernet. Isn't standard (not even de facto standard, like
SLIP).
Performance
===========
PLIP easily outperforms Ethernet cards....(ups, I was dreaming, but
it *is* getting late. EOB)
Driver, IRQ와 trigger timeout
61-112Linux PLIP driver는 원래 Crynwr protocol을 구현합니다. Kernel의 parallel port subsystem을 사용하여 PLIP와 다른 service가 parallel port를 올바르게 공유하도록 합니다.
PLIP용 parallel port에 IRQ가 설정되어 있으면 cable로 data가 들어올 때 driver가 signal을 받으므로 data가 없을 때는 driver가 CPU를 사용하지 않습니다.
다른 device가 IRQ를 사용하여 parallel port에 IRQ를 설정하기 어렵거나 불가능한 machine에서는 IRQ-less mode를 쓸 수 있습니다. 이 mode는 driver가 data를 기다리며 port를 계속 polling합니다. Data가 전혀 없어도 초당 여러 번 확인하므로 IRQ mode보다 효율이 낮습니다. 대략적인 측정에서는 전송 속도 자체의 눈에 띄는 저하는 없었지만 driver를 실행하는 machine의 전체 성능은 떨어집니다.
IRQ mode에서 전송 handshake를 시작할 때 상대를 기다리는 trigger timeout 기본값은 500usec입니다. IRQ delivery가 거의 즉시 이루어지므로 이 값이면 충분합니다.
IRQ-less mode는 초당 `HZ`회 port를 polling합니다. 두 poll 간격은 `10^6/HZ` usec입니다. 예를 들어 i386의 `HZ=100`이면 10,000usec이므로 500usec timeout이 다음 poll 전에 만료될 수 있습니다. 따라서 연결의 반대편 trigger timeout을 약 `10^6/HZ` usec로 바꿔야 하며 양쪽이 IRQ-less이면 양쪽 모두 바꿔야 합니다.
실제로는 계산값보다 짧은 timeout도 가능할 수 있습니다. 다만 cable에 결함이 있어 bit가 손실될 때 긴 timeout은 machine을 오래 멈추게 할 수 있습니다.
Linux에서는 net-tools package의 `plipconfig`로 timeout을 바꿀 수 있습니다. 예를 들어 `plipconfig plipX trigger 10000`은 해당 PLIP device의 trigger timeout을 10,000usec로 설정합니다.
Polling 간격과 timeout 설정의 차이입니다.
수신 측 poll 간격보다 송신 측 handshake timeout이 짧지 않아야 합니다.
PLIP driver details
-------------------
The Linux PLIP driver is an implementation of the original Crynwr protocol,
that uses the parallel port subsystem of the kernel in order to properly
share parallel ports between PLIP and other services.
IRQs and trigger timeouts
=========================
When a parallel port used for a PLIP driver has an IRQ configured to it, the
PLIP driver is signaled whenever data is sent to it via the cable, such that
when no data is available, the driver isn't being used.
However, on some machines it is hard, if not impossible, to configure an IRQ
to a certain parallel port, mainly because it is used by some other device.
On these machines, the PLIP driver can be used in IRQ-less mode, where
the PLIP driver would constantly poll the parallel port for data waiting,
and if such data is available, process it. This mode is less efficient than
the IRQ mode, because the driver has to check the parallel port many times
per second, even when no data at all is sent. Some rough measurements
indicate that there isn't a noticeable performance drop when using IRQ-less
mode as compared to IRQ mode as far as the data transfer speed is involved.
There is a performance drop on the machine hosting the driver.
When the PLIP driver is used in IRQ mode, the timeout used for triggering a
data transfer (the maximal time the PLIP driver would allow the other side
before announcing a timeout, when trying to handshake a transfer of some
data) is, by default, 500usec. As IRQ delivery is more or less immediate,
this timeout is quite sufficient.
When in IRQ-less mode, the PLIP driver polls the parallel port HZ times
per second (where HZ is typically 100 on most platforms, and 1024 on an
Alpha, as of this writing). Between two such polls, there are 10^6/HZ usecs.
On an i386, for example, 10^6/100 = 10000usec. It is easy to see that it is
quite possible for the trigger timeout to expire between two such polls, as
the timeout is only 500usec long. As a result, it is required to change the
trigger timeout on the *other* side of a PLIP connection, to about
10^6/HZ usecs. If both sides of a PLIP connection are used in IRQ-less mode,
this timeout is required on both sides.
It appears that in practice, the trigger timeout can be shorter than in the
above calculation. It isn't an important issue, unless the wire is faulty,
in which case a long timeout would stall the machine when, for whatever
reason, bits are dropped.
A utility that can perform this change in Linux is plipconfig, which is part
of the net-tools package (its location can be found in the
Documentation/Changes file). An example command would be
'plipconfig plipX trigger 10000', where plipX is the appropriate
PLIP device.
Nibble 전송과 byte-wide 전송
113-125PLIP은 여러 data transfer method를 사용합니다. 초기 코드에 구현된 첫 방식은 표준 printer null cable로 한 번에 4bit씩 전송합니다. 한 port의 data bit output을 다른 port의 status bit input에 연결합니다.
두 번째 방식은 두 machine 모두 output-only printer port가 아니라 bidirectional parallel port를 갖는다는 조건에 의존합니다. 한 번에 1byte를 전송하므로 두 nibble을 byte로 다시 조립할 필요가 없고 훨씬 빠릅니다.
Port 방향성과 전송 폭의 차이입니다.
PLIP hardware interconnection
-----------------------------
PLIP uses several different data transfer methods. The first (and the
only one implemented in the early version of the code) uses a standard
printer "null" cable to transfer data four bits at a time using
data bit outputs connected to status bit inputs.
The second data transfer method relies on both machines having
bi-directional parallel ports, rather than output-only ``printer``
ports. This allows byte-wide transfers and avoids reconstructing
nibbles into bytes, leading to much faster transfers.
Parallel Transfer Mode 0 cable
126-158Mode 0 cable은 machine T의 data output 4bit를 machine R의 status input에 연결하는 표준 printer null cable입니다. 다섯 개 status input 중 네 개는 data, 하나는 clock 또는 data strobe로 사용합니다. 표준 status register에서 data input bit가 연속된 bit처럼 나타나도록 배치합니다.
상용 명칭은 Null Printer 또는 Turbo Laplink cable입니다. DB-25 male connector 두 개를 대칭으로 연결합니다. D0~D4는 반대편 ERROR·SLCT·PAPOUT·ACK·BUSY로 교차 연결하고 `SLCTIN`과 `GROUND`는 같은 pin 번호끼리 연결합니다.
Pin 1, 7, 8, 9, 14, 16과 추가 ground 18~24는 양쪽 모두 연결하지 않습니다. Cable에 금속 shield가 있으면 한쪽 끝의 금속 DB-25 shell에만 연결하여 ground loop를 피합니다.
두 connector 사이의 대칭 교차 연결입니다.
각 방향에서 data output이 반대편 status input으로 들어갑니다.
Parallel Transfer Mode 0 Cable
==============================
The cable for the first transfer mode is a standard
printer "null" cable which transfers data four bits at a time using
data bit outputs of the first port (machine T) connected to the
status bit inputs of the second port (machine R). There are five
status inputs, and they are used as four data inputs and a clock (data
strobe) input, arranged so that the data input bits appear as contiguous
bits with standard status register implementation.
A cable that implements this protocol is available commercially as a
"Null Printer" or "Turbo Laplink" cable. It can be constructed with
two DB-25 male connectors symmetrically connected as follows::
STROBE output 1*
D0->ERROR 2 - 15 15 - 2
D1->SLCT 3 - 13 13 - 3
D2->PAPOUT 4 - 12 12 - 4
D3->ACK 5 - 10 10 - 5
D4->BUSY 6 - 11 11 - 6
D5,D6,D7 are 7*, 8*, 9*
AUTOFD output 14*
INIT output 16*
SLCTIN 17 - 17
extra grounds are 18*,19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Do not connect these pins on either end
If the cable you are using has a metallic shield it should be
connected to the metallic DB-25 shell at one end only.
Parallel Transfer Mode 1 cable
159-192Mode 1은 양쪽 모두 bidirectional parallel port일 때 byte-wide transfer를 사용합니다. Nibble을 byte로 재구성하지 않아도 됩니다.
이 cable을 unidirectional printer port에 연결하거나 machine이 PLIP용으로 설정되지 않은 상태에서 사용하면 output driver끼리 충돌할 수 있고, 가능성은 낮지만 hardware 손상도 일어날 수 있으므로 사용해서는 안 됩니다.
D0~D7은 양쪽 같은 pin 2~9에 직결합니다. Control과 status handshake는 STROBE→BUSY, INIT→ACK, AUTOFD→PAPOUT, SLCT→SLCTIN으로 연결합니다. Pin 18은 반대편 ERROR pin 15에 연결하고 pin 25 ground는 직결합니다.
추가 ground pin 19~24는 양쪽 모두 연결하지 않습니다. 금속 shield는 Mode 0과 마찬가지로 한쪽 DB-25 shell에만 연결합니다.
Byte data bus와 handshake line 연결입니다.
Parallel Transfer Mode 1
========================
The second data transfer method relies on both machines having
bi-directional parallel ports, rather than output-only ``printer``
ports. This allows byte-wide transfers, and avoids reconstructing
nibbles into bytes. This cable should not be used on unidirectional
``printer`` (as opposed to ``parallel``) ports or when the machine
isn't configured for PLIP, as it will result in output driver
conflicts and the (unlikely) possibility of damage.
The cable for this transfer mode should be constructed as follows::
STROBE->BUSY 1 - 11
D0->D0 2 - 2
D1->D1 3 - 3
D2->D2 4 - 4
D3->D3 5 - 5
D4->D4 6 - 6
D5->D5 7 - 7
D6->D6 8 - 8
D7->D7 9 - 9
INIT -> ACK 16 - 10
AUTOFD->PAPOUT 14 - 12
SLCT->SLCTIN 13 - 17
GND->ERROR 18 - 15
extra grounds are 19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Do not connect these pins on either end
Once again, if the cable you are using has a metallic shield it should
be connected to the metallic DB-25 shell at one end only.
Crynwr Mode 0 전송 handshake
193-222PLIP driver의 Mode 0은 Crynwr parallel-port transfer 표준과 호환됩니다. Frame은 header nibble `0x8`, count의 low octet, count의 high octet, 이어지는 data octet들, checksum octet 순서입니다.
각 octet은 두 nibble로 보냅니다. 먼저 receiver가 `0x1?` 상태가 될 때까지 기다린 뒤 `0x10 + (octet & 0x0F)`로 low nibble과 strobe bit를 보냅니다. 다음으로 receiver가 `0x0?`가 될 때까지 기다리고 `0x00 + ((octet >> 4) & 0x0F)`로 high nibble을 보냅니다.
전송을 시작할 때 송신 machine은 nibble `0x08`을 출력합니다. 이 신호가 ACK line을 올려 수신 machine에 interrupt를 발생시킵니다. 수신 machine은 interrupt를 비활성화하고 자신의 ACK line을 올립니다.
원문의 재서술에서 `OUT`과 `IN`은 bit 0~4이며 `OUT.j`는 OUT의 bit j입니다. `Send_Byte`는 low nibble과 `OUT.4=1`을 출력하고 `IN.4=1`을 기다린 뒤, high nibble과 `OUT.4=0`을 출력하고 `IN.4=0`을 기다리는 네 단계 handshake입니다.
Nibble header 뒤에 길이, data와 checksum을 보냅니다.
Octet 하나를 low·high nibble과 ACK 상태로 전송합니다.
PLIP Mode 0 transfer protocol
=============================
The PLIP driver is compatible with the "Crynwr" parallel port transfer
standard in Mode 0. That standard specifies the following protocol::
send header nibble '0x8'
count-low octet
count-high octet
... data octets
checksum octet
Each octet is sent as::
<wait for rx. '0x1?'> <send 0x10+(octet&0x0F)>
<wait for rx. '0x0?'> <send 0x00+((octet>>4)&0x0F)>
To start a transfer the transmitting machine outputs a nibble 0x08.
That raises the ACK line, triggering an interrupt in the receiving
machine. The receiving machine disables interrupts and raises its own ACK
line.
Restated::
(OUT is bit 0-4, OUT.j is bit j from OUT. IN likewise)
Send_Byte:
OUT := low nibble, OUT.4 := 1
WAIT FOR IN.4 = 1
OUT := high nibble, OUT.4 := 0
WAIT FOR IN.4 = 0
요약·해설
plip.rst:1-222PLIP은 두 parallel port와 null-printer cable을 IP interface로 사용하는 비표준 point-to-point protocol입니다. Mode 0은 status line을 이용한 4bit Crynwr handshake를, Mode 1은 bidirectional port의 8bit 전송을 사용하며 IRQ-less 동작에서는 polling 주기에 맞춘 trigger timeout 조정이 필요합니다.
Parallel cable이 두 Linux machine 사이의 IP network interface가 됩니다.