요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
===============================================================
HVCS IBM "Hypervisor Virtual Console Server" Installation Guide
===============================================================
for Linux Kernel 2.6.4+
Copyright (C) 2004 IBM Corporation
.. ===========================================================================
.. NOTE:Eight space tabs are the optimum editor setting for reading this file.
.. ===========================================================================
Author(s): Ryan S. Arnold <rsa@us.ibm.com>
Date Created: March, 02, 2004
Last Changed: August, 24, 2004
.. Table of contents:
1. Driver Introduction:
2. System Requirements
3. Build Options:
3.1 Built-in:
3.2 Module:
4. Installation:
5. Connection:
6. Disconnection:
7. Configuration:
8. Questions & Answers:
9. Reporting Bugs:
1. Driver Introduction:
=======================
This is the device driver for the IBM Hypervisor Virtual Console Server,
"hvcs". The IBM hvcs provides a tty driver interface to allow Linux user
space applications access to the system consoles of logically partitioned
operating systems (Linux and AIX) running on the same partitioned Power5
ppc64 system. Physical hardware consoles per partition are not practical
on this hardware so system consoles are accessed by this driver using
firmware interfaces to virtual terminal devices.
2. System Requirements:
=======================
This device driver was written using 2.6.4 Linux kernel APIs and will only
build and run on kernels of this version or later.
This driver was written to operate solely on IBM Power5 ppc64 hardware
though some care was taken to abstract the architecture dependent firmware
calls from the driver code.
Sysfs must be mounted on the system so that the user can determine which
major and minor numbers are associated with each vty-server. Directions
for sysfs mounting are outside the scope of this document.
3. Build Options:
=================
The hvcs driver registers itself as a tty driver. The tty layer
dynamically allocates a block of major and minor numbers in a quantity
requested by the registering driver. The hvcs driver asks the tty layer
for 64 of these major/minor numbers by default to use for hvcs device node
entries.
If the default number of device entries is adequate then this driver can be
built into the kernel. If not, the default can be over-ridden by inserting
the driver as a module with insmod parameters.
3.1 Built-in:
-------------
The following menuconfig example demonstrates selecting to build this
driver into the kernel::
Device Drivers --->
Character devices --->
<*> IBM Hypervisor Virtual Console Server Support
Begin the kernel make process.
3.2 Module:
-----------
The following menuconfig example demonstrates selecting to build this
driver as a kernel module::
Device Drivers --->
Character devices --->
<M> IBM Hypervisor Virtual Console Server Support
The make process will build the following kernel modules:
- hvcs.ko
- hvcserver.ko
To insert the module with the default allocation execute the following
commands in the order they appear::
insmod hvcserver.ko
insmod hvcs.ko
The hvcserver module contains architecture specific firmware calls and must
be inserted first, otherwise the hvcs module will not find some of the
symbols it expects.
To override the default use an insmod parameter as follows (requesting 4
tty devices as an example)::
insmod hvcs.ko hvcs_parm_num_devs=4
There is a maximum number of dev entries that can be specified on insmod.
We think that 1024 is currently a decent maximum number of server adapters
to allow. This can always be changed by modifying the constant in the
source file before building.
NOTE: The length of time it takes to insmod the driver seems to be related
to the number of tty interfaces the registering driver requests.
In order to remove the driver module execute the following command::
rmmod hvcs.ko
The recommended method for installing hvcs as a module is to use depmod to
build a current modules.dep file in /lib/modules/`uname -r` and then
execute::
modprobe hvcs hvcs_parm_num_devs=4
The modules.dep file indicates that hvcserver.ko needs to be inserted
before hvcs.ko and modprobe uses this file to smartly insert the modules in
the proper order.
The following modprobe command is used to remove hvcs and hvcserver in the
proper order::
modprobe -r hvcs
4. Installation:
================
The tty layer creates sysfs entries which contain the major and minor
numbers allocated for the hvcs driver. The following snippet of "tree"
output of the sysfs directory shows where these numbers are presented::
sys/
|-- *other sysfs base dirs*
|
|-- class
| |-- *other classes of devices*
| |
| `-- tty
| |-- *other tty devices*
| |
| |-- hvcs0
| | `-- dev
| |-- hvcs1
| | `-- dev
| |-- hvcs2
| | `-- dev
| |-- hvcs3
| | `-- dev
| |
| |-- *other tty devices*
|
|-- *other sysfs base dirs*
For the above examples the following output is a result of cat'ing the
"dev" entry in the hvcs directory::
Pow5:/sys/class/tty/hvcs0/ # cat dev
254:0
Pow5:/sys/class/tty/hvcs1/ # cat dev
254:1
Pow5:/sys/class/tty/hvcs2/ # cat dev
254:2
Pow5:/sys/class/tty/hvcs3/ # cat dev
254:3
The output from reading the "dev" attribute is the char device major and
minor numbers that the tty layer has allocated for this driver's use. Most
systems running hvcs will already have the device entries created or udev
will do it automatically.
Given the example output above, to manually create a /dev/hvcs* node entry
mknod can be used as follows::
mknod /dev/hvcs0 c 254 0
mknod /dev/hvcs1 c 254 1
mknod /dev/hvcs2 c 254 2
mknod /dev/hvcs3 c 254 3
Using mknod to manually create the device entries makes these device nodes
persistent. Once created they will exist prior to the driver insmod.
Attempting to connect an application to /dev/hvcs* prior to insertion of
the hvcs module will result in an error message similar to the following::
"/dev/hvcs*: No such device".
NOTE: Just because there is a device node present doesn't mean that there
is a vty-server device configured for that node.
5. Connection
=============
Since this driver controls devices that provide a tty interface a user can
interact with the device node entries using any standard tty-interactive
method (e.g. "cat", "dd", "echo"). The intent of this driver however, is
to provide real time console interaction with a Linux partition's console,
which requires the use of applications that provide bi-directional,
interactive I/O with a tty device.
Applications (e.g. "minicom" and "screen") that act as terminal emulators
or perform terminal type control sequence conversion on the data being
passed through them are NOT acceptable for providing interactive console
I/O. These programs often emulate antiquated terminal types (vt100 and
ANSI) and expect inbound data to take the form of one of these supported
terminal types but they either do not convert, or do not _adequately_
convert, outbound data into the terminal type of the terminal which invoked
them (though screen makes an attempt and can apparently be configured with
much termcap wrestling.)
For this reason kermit and cu are two of the recommended applications for
interacting with a Linux console via an hvcs device. These programs simply
act as a conduit for data transfer to and from the tty device. They do not
require inbound data to take the form of a particular terminal type, nor do
they cook outbound data to a particular terminal type.
In order to ensure proper functioning of console applications one must make
sure that once connected to a /dev/hvcs console that the console's $TERM
env variable is set to the exact terminal type of the terminal emulator
used to launch the interactive I/O application. If one is using xterm and
kermit to connect to /dev/hvcs0 when the console prompt becomes available
one should "export TERM=xterm" on the console. This tells ncurses
applications that are invoked from the console that they should output
control sequences that xterm can understand.
As a precautionary measure an hvcs user should always "exit" from their
session before disconnecting an application such as kermit from the device
node. If this is not done, the next user to connect to the console will
continue using the previous user's logged in session which includes
using the $TERM variable that the previous user supplied.
Hotplug add and remove of vty-server adapters affects which /dev/hvcs* node
is used to connect to each vty-server adapter. In order to determine which
vty-server adapter is associated with which /dev/hvcs* node a special sysfs
attribute has been added to each vty-server sysfs entry. This entry is
called "index" and showing it reveals an integer that refers to the
/dev/hvcs* entry to use to connect to that device. For instance cating the
index attribute of vty-server adapter 30000004 shows the following::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat index
2
This index of '2' means that in order to connect to vty-server adapter
30000004 the user should interact with /dev/hvcs2.
It should be noted that due to the system hotplug I/O capabilities of a
system the /dev/hvcs* entry that interacts with a particular vty-server
adapter is not guaranteed to remain the same across system reboots. Look
in the Q & A section for more on this issue.
6. Disconnection
================
As a security feature to prevent the delivery of stale data to an
unintended target the Power5 system firmware disables the fetching of data
and discards that data when a connection between a vty-server and a vty has
been severed. As an example, when a vty-server is immediately disconnected
from a vty following output of data to the vty the vty adapter may not have
enough time between when it received the data interrupt and when the
connection was severed to fetch the data from firmware before the fetch is
disabled by firmware.
When hvcs is being used to serve consoles this behavior is not a huge issue
because the adapter stays connected for large amounts of time following
almost all data writes. When hvcs is being used as a tty conduit to tunnel
data between two partitions [see Q & A below] this is a huge problem
because the standard Linux behavior when cat'ing or dd'ing data to a device
is to open the tty, send the data, and then close the tty. If this driver
manually terminated vty-server connections on tty close this would close
the vty-server and vty connection before the target vty has had a chance to
fetch the data.
Additionally, disconnecting a vty-server and vty only on module removal or
adapter removal is impractical because other vty-servers in other
partitions may require the usage of the target vty at any time.
Due to this behavioral restriction disconnection of vty-servers from the
connected vty is a manual procedure using a write to a sysfs attribute
outlined below, on the other hand the initial vty-server connection to a
vty is established automatically by this driver. Manual vty-server
connection is never required.
In order to terminate the connection between a vty-server and vty the
"vterm_state" sysfs attribute within each vty-server's sysfs entry is used.
Reading this attribute reveals the current connection state of the
vty-server adapter. A zero means that the vty-server is not connected to a
vty. A one indicates that a connection is active.
Writing a '0' (zero) to the vterm_state attribute will disconnect the VTERM
connection between the vty-server and target vty ONLY if the vterm_state
previously read '1'. The write directive is ignored if the vterm_state
read '0' or if any value other than '0' was written to the vterm_state
attribute. The following example will show the method used for verifying
the vty-server connection status and disconnecting a vty-server connection::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat vterm_state
1
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # echo 0 > vterm_state
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat vterm_state
0
All vty-server connections are automatically terminated when the device is
hotplug removed and when the module is removed.
7. Configuration
================
Each vty-server has a sysfs entry in the /sys/devices/vio directory, which
is symlinked in several other sysfs tree directories, notably under the
hvcs driver entry, which looks like the following example::
Pow5:/sys/bus/vio/drivers/hvcs # ls
. .. 30000003 30000004 rescan
By design, firmware notifies the hvcs driver of vty-server lifetimes and
partner vty removals but not the addition of partner vtys. Since an HMC
Super Admin can add partner info dynamically we have provided the hvcs
driver sysfs directory with the "rescan" update attribute which will query
firmware and update the partner info for all the vty-servers that this
driver manages. Writing a '1' to the attribute triggers the update. An
explicit example follows:
Pow5:/sys/bus/vio/drivers/hvcs # echo 1 > rescan
Reading the attribute will indicate a state of '1' or '0'. A one indicates
that an update is in process. A zero indicates that an update has
completed or was never executed.
Vty-server entries in this directory are a 32 bit partition unique unit
address that is created by firmware. An example vty-server sysfs entry
looks like the following::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # ls
. current_vty devspec name partner_vtys
.. index partner_clcs vterm_state
Each entry is provided, by default with a "name" attribute. Reading the
"name" attribute will reveal the device type as shown in the following
example::
Pow5:/sys/bus/vio/drivers/hvcs/30000003 # cat name
vty-server
Each entry is also provided, by default, with a "devspec" attribute which
reveals the full device specification when read, as shown in the following
example::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat devspec
/vdevice/vty-server@30000004
Each vty-server sysfs dir is provided with two read-only attributes that
provide lists of easily parsed partner vty data: "partner_vtys" and
"partner_clcs"::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat partner_vtys
30000000
30000001
30000002
30000000
30000000
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat partner_clcs
U5112.428.103048A-V3-C0
U5112.428.103048A-V3-C2
U5112.428.103048A-V3-C3
U5112.428.103048A-V4-C0
U5112.428.103048A-V5-C0
Reading partner_vtys returns a list of partner vtys. Vty unit address
numbering is only per-partition-unique so entries will frequently repeat.
Reading partner_clcs returns a list of "converged location codes" which are
composed of a system serial number followed by "-V*", where the '*' is the
target partition number, and "-C*", where the '*' is the slot of the
adapter. The first vty partner corresponds to the first clc item, the
second vty partner to the second clc item, etc.
A vty-server can only be connected to a single vty at a time. The entry,
"current_vty" prints the clc of the currently selected partner vty when
read.
The current_vty can be changed by writing a valid partner clc to the entry
as in the following example::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # echo U5112.428.10304
8A-V4-C0 > current_vty
Changing the current_vty when a vty-server is already connected to a vty
does not affect the current connection. The change takes effect when the
currently open connection is freed.
Information on the "vterm_state" attribute was covered earlier on the
chapter entitled "disconnection".
8. Questions & Answers:
=======================
Q: What are the security concerns involving hvcs?
A: There are three main security concerns:
1. The creator of the /dev/hvcs* nodes has the ability to restrict
the access of the device entries to certain users or groups. It
may be best to create a special hvcs group privilege for providing
access to system consoles.
2. To provide network security when grabbing the console it is
suggested that the user connect to the console hosting partition
using a secure method, such as SSH or sit at a hardware console.
3. Make sure to exit the user session when done with a console or
the next vty-server connection (which may be from another
partition) will experience the previously logged in session.
---------------------------------------------------------------------------
Q: How do I multiplex a console that I grab through hvcs so that other
people can see it:
A: You can use "screen" to directly connect to the /dev/hvcs* device and
setup a session on your machine with the console group privileges. As
pointed out earlier by default screen doesn't provide the termcap settings
for most terminal emulators to provide adequate character conversion from
term type "screen" to others. This means that curses based programs may
not display properly in screen sessions.
---------------------------------------------------------------------------
Q: Why are the colors all messed up?
Q: Why are the control characters acting strange or not working?
Q: Why is the console output all strange and unintelligible?
A: Please see the preceding section on "Connection" for a discussion of how
applications can affect the display of character control sequences.
Additionally, just because you logged into the console using and xterm
doesn't mean someone else didn't log into the console with the HMC console
(vt320) before you and leave the session logged in. The best thing to do
is to export TERM to the terminal type of your terminal emulator when you
get the console. Additionally make sure to "exit" the console before you
disconnect from the console. This will ensure that the next user gets
their own TERM type set when they login.
---------------------------------------------------------------------------
Q: When I try to CONNECT kermit to an hvcs device I get:
"Sorry, can't open connection: /dev/hvcs*"What is happening?
A: Some other Power5 console mechanism has a connection to the vty and
isn't giving it up. You can try to force disconnect the consoles from the
HMC by right clicking on the partition and then selecting "close terminal".
Otherwise you have to hunt down the people who have console authority. It
is possible that you already have the console open using another kermit
session and just forgot about it. Please review the console options for
Power5 systems to determine the many ways a system console can be held.
OR
A: Another user may not have a connectivity method currently attached to a
/dev/hvcs device but the vterm_state may reveal that they still have the
vty-server connection established. They need to free this using the method
outlined in the section on "Disconnection" in order for others to connect
to the target vty.
OR
A: The user profile you are using to execute kermit probably doesn't have
permissions to use the /dev/hvcs* device.
OR
A: You probably haven't inserted the hvcs.ko module yet but the /dev/hvcs*
entry still exists (on systems without udev).
OR
A: There is not a corresponding vty-server device that maps to an existing
/dev/hvcs* entry.
---------------------------------------------------------------------------
Q: When I try to CONNECT kermit to an hvcs device I get:
"Sorry, write access to UUCP lockfile directory denied."
A: The /dev/hvcs* entry you have specified doesn't exist where you said it
does? Maybe you haven't inserted the module (on systems with udev).
---------------------------------------------------------------------------
Q: If I already have one Linux partition installed can I use hvcs on said
partition to provide the console for the install of a second Linux
partition?
A: Yes granted that your are connected to the /dev/hvcs* device using
kermit or cu or some other program that doesn't provide terminal emulation.
---------------------------------------------------------------------------
Q: Can I connect to more than one partition's console at a time using this
driver?
A: Yes. Of course this means that there must be more than one vty-server
configured for this partition and each must point to a disconnected vty.
---------------------------------------------------------------------------
Q: Does the hvcs driver support dynamic (hotplug) addition of devices?
A: Yes, if you have dlpar and hotplug enabled for your system and it has
been built into the kernel the hvcs drivers is configured to dynamically
handle additions of new devices and removals of unused devices.
---------------------------------------------------------------------------
Q: For some reason /dev/hvcs* doesn't map to the same vty-server adapter
after a reboot. What happened?
A: Assignment of vty-server adapters to /dev/hvcs* entries is always done
in the order that the adapters are exposed. Due to hotplug capabilities of
this driver assignment of hotplug added vty-servers may be in a different
order than how they would be exposed on module load. Rebooting or
reloading the module after dynamic addition may result in the /dev/hvcs*
and vty-server coupling changing if a vty-server adapter was added in a
slot between two other vty-server adapters. Refer to the section above
on how to determine which vty-server goes with which /dev/hvcs* node.
Hint; look at the sysfs "index" attribute for the vty-server.
---------------------------------------------------------------------------
Q: Can I use /dev/hvcs* as a conduit to another partition and use a tty
device on that partition as the other end of the pipe?
A: Yes, on Power5 platforms the hvc_console driver provides a tty interface
for extra /dev/hvc* devices (where /dev/hvc0 is most likely the console).
In order to get a tty conduit working between the two partitions the HMC
Super Admin must create an additional "serial server" for the target
partition with the HMC gui which will show up as /dev/hvc* when the target
partition is rebooted.
The HMC Super Admin then creates an additional "serial client" for the
current partition and points this at the target partition's newly created
"serial server" adapter (remember the slot). This shows up as an
additional /dev/hvcs* device.
Now a program on the target system can be configured to read or write to
/dev/hvc* and another program on the current partition can be configured to
read or write to /dev/hvcs*. Now you have a tty conduit between two
partitions.
---------------------------------------------------------------------------
9. Reporting Bugs:
==================
The proper channel for reporting bugs is either through the Linux OS
distribution company that provided your OS or by posting issues to the
PowerPC development mailing list at:
linuxppc-dev@lists.ozlabs.org
This request is to provide a documented and searchable public exchange
of the problems and solutions surrounding this driver for the benefit of
all users.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
HVCS 설치 안내서와 문서 정보
1-32이 문서는 Linux 2.6.4 이상을 위한 IBM Hypervisor Virtual Console Server (`hvcs`) 설치 안내서입니다. IBM Corporation이 2004년에 작성했으며 저자는 Ryan S. Arnold입니다.
문서는 드라이버 소개, 시스템 요구 사항, 내장/모듈 빌드, 설치, 연결과 해제, 구성, 질문과 답변, 버그 보고 순서로 구성됩니다.
드라이버 소개
33-43IBM `hvcs`는 같은 partitioned Power5 ppc64 시스템에서 실행되는 논리 partition 운영체제(Linux와 AIX)의 system console에 Linux userspace application이 접근할 수 있도록 tty driver interface를 제공합니다.
이 하드웨어에서는 partition마다 물리 console을 두는 방식이 실용적이지 않습니다. 따라서 드라이버가 firmware interface와 virtual terminal device를 사용해 system console에 접근합니다.
시스템 요구 사항
44-57드라이버는 Linux 2.6.4 kernel API를 기준으로 작성되었으므로 이 버전 이상의 kernel에서만 빌드하고 실행할 수 있습니다.
대상은 IBM Power5 ppc64 하드웨어이며, architecture-dependent firmware call은 가능한 한 driver code에서 분리했습니다.
각 vty-server에 배정된 major/minor number를 확인하려면 sysfs가 mount되어 있어야 합니다. sysfs mount 방법은 이 문서의 범위를 벗어납니다.
빌드 선택과 장치 수
58-70`hvcs`는 tty driver로 등록됩니다. tty layer는 드라이버가 요청한 수만큼 major/minor number block을 동적으로 할당하며, `hvcs`의 기본 요청 수는 64개입니다.
기본 장치 수가 충분하면 kernel에 내장할 수 있습니다. 더 많은 수가 필요하면 module로 빌드한 뒤 `insmod` parameter로 기본값을 덮어씁니다.
Kernel 내장 빌드
71-82`menuconfig`에서 다음 항목을 내장(`*`)으로 선택합니다.
Device Drivers --->
Character devices --->
<*> IBM Hypervisor Virtual Console Server Support
선택을 마친 뒤 일반 kernel build 절차를 시작합니다.
Module 빌드, 적재와 제거
83-139Module(`M`)로 빌드하려면 다음 항목을 선택합니다.
Device Drivers --->
Character devices --->
<M> IBM Hypervisor Virtual Console Server Support
The make process will build the following kernel modules:
- hvcs.ko
- hvcserver.ko
Build 결과는 `hvcs.ko`와 `hvcserver.ko`입니다. Architecture-specific firmware call을 제공하는 `hvcserver.ko`를 먼저 넣어야 `hvcs.ko`가 필요한 symbol을 찾을 수 있습니다.
insmod hvcserver.ko
insmod hvcs.ko
예를 들어 tty device 4개를 요청하려면 `hvcs_parm_num_devs=4`를 사용합니다.
insmod hvcs.ko hvcs_parm_num_devs=4
Module insert 시 요청할 수 있는 server adapter 수에는 상한이 있으며 문서 작성 당시 기본 최대값은 1024입니다. 필요하면 build 전에 source constant를 바꿀 수 있습니다. 요청한 tty interface 수가 많을수록 module insert 시간이 길어지는 경향이 있습니다.
직접 제거할 때는 다음 명령을 사용합니다.
rmmod hvcs.ko
권장 설치 방식은 `depmod`로 `/lib/modules/`uname -r`/modules.dep`를 최신화한 뒤 `modprobe`를 사용하는 것입니다. Dependency file을 통해 `hvcserver.ko`가 먼저 적재됩니다.
modprobe hvcs hvcs_parm_num_devs=4
두 module을 올바른 순서로 제거하려면 다음 명령을 사용합니다.
modprobe -r hvcs
Sysfs 번호 확인과 device node 설치
140-207tty layer는 `hvcs`에 배정한 major/minor number를 sysfs에 공개합니다. `/sys/class/tty/hvcsN/dev`가 각 번호를 담습니다.
sys/
|-- *other sysfs base dirs*
|
|-- class
| |-- *other classes of devices*
| |
| `-- tty
| |-- *other tty devices*
| |
| |-- hvcs0
| | `-- dev
| |-- hvcs1
| | `-- dev
| |-- hvcs2
| | `-- dev
| |-- hvcs3
| | `-- dev
| |
| |-- *other tty devices*
|
|-- *other sysfs base dirs*
Sysfs의 tty class에서 각 hvcs instance와 major/minor pair를 찾습니다.
예시 system은 `hvcs0`부터 `hvcs3`에 `254:0`부터 `254:3`을 배정했습니다.
Pow5:/sys/class/tty/hvcs0/ # cat dev
254:0
Pow5:/sys/class/tty/hvcs1/ # cat dev
254:1
Pow5:/sys/class/tty/hvcs2/ # cat dev
254:2
Pow5:/sys/class/tty/hvcs3/ # cat dev
254:3
대부분의 system은 device node를 이미 만들었거나 udev가 자동으로 만듭니다. 수동으로 만들 경우 `mknod`에 sysfs에서 읽은 번호를 전달합니다.
mknod /dev/hvcs0 c 254 0
mknod /dev/hvcs1 c 254 1
mknod /dev/hvcs2 c 254 2
mknod /dev/hvcs3 c 254 3
수동 생성한 node는 module이 제거되어도 남습니다. 따라서 node 존재 자체가 해당 node에 vty-server가 구성되었다는 뜻은 아닙니다. Module을 넣기 전에 열면 다음과 같은 오류가 납니다.
"/dev/hvcs*: No such device".
Console 연결과 terminal 선택
208-267`/dev/hvcs*`는 tty이므로 `cat`, `dd`, `echo` 같은 표준 방법으로 접근할 수 있지만, 실제 console 상호작용에는 양방향 interactive I/O application이 필요합니다.
`minicom`과 `screen`처럼 terminal emulation이나 control-sequence 변환을 수행하는 application은 이 용도에 적합하지 않습니다. 오래된 `vt100`/ANSI 형식을 가정하거나 outbound data를 호출 terminal 형식으로 충분히 변환하지 못할 수 있습니다.
`kermit`과 `cu`는 data를 가공하지 않는 conduit로 동작하므로 권장됩니다. 연결한 console에서는 실행한 terminal emulator와 정확히 일치하도록 `$TERM`을 설정해야 합니다. 예를 들어 xterm에서 kermit으로 연결했다면 console에서 `export TERM=xterm`을 실행합니다.
연결 application을 끊기 전에 console session에서 반드시 `exit`하십시오. 그렇지 않으면 다음 사용자가 이전 login session과 `$TERM` 설정을 이어받습니다.
Hotplug로 vty-server가 추가·제거되면 특정 server가 사용하는 `/dev/hvcsN`도 바뀔 수 있습니다. 각 vty-server의 `index` attribute가 현재 연결할 node 번호를 알려 줍니다.
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat index
2
위 결과 `2`는 vty-server `30000004`에 `/dev/hvcs2`로 접근하라는 뜻입니다. 재부팅 후에도 같은 번호가 유지된다고 가정해서는 안 됩니다.
연결 해제와 stale data 방지
268-323Power5 firmware는 stale data가 의도하지 않은 대상에 전달되지 않도록 vty-server와 vty 연결이 끊기면 data fetch를 막고 남은 data를 버립니다. 출력 직후 너무 빨리 끊으면 target vty가 firmware에서 data를 가져오기 전에 폐기될 수 있습니다.
Console은 대개 오랫동안 열려 있어 영향이 작지만 partition 사이 tty conduit로 `cat`이나 `dd`를 쓰면 open, write, close가 빠르게 이어집니다. tty close 때마다 driver가 연결을 끊으면 target이 data를 가져오기 전에 연결이 사라질 수 있습니다.
반대로 module 제거나 adapter 제거 때만 끊는 것도 다른 partition의 vty-server가 target vty를 필요로 할 수 있어 적합하지 않습니다. 그래서 최초 연결은 driver가 자동으로 만들고, 해제는 sysfs를 통한 수동 절차로 둡니다.
`vterm_state`를 읽어 `1`이면 연결됨, `0`이면 연결되지 않음입니다. 기존 상태가 `1`일 때만 `0` 쓰기가 연결을 끊습니다. 다른 값 또는 이미 `0`인 상태의 쓰기는 무시됩니다.
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat vterm_state
1
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # echo 0 > vterm_state
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat vterm_state
0
현재 상태를 확인한 뒤 active connection에만 disconnect를 요청합니다.
Device hot-remove와 module 제거 때는 모든 vty-server 연결이 자동으로 종료됩니다.
Vty-server sysfs 구성
324-413각 vty-server는 `/sys/devices/vio` 아래에 entry를 가지며 여러 sysfs 위치에 symlink됩니다. Driver directory에는 server unit address와 `rescan`이 나타납니다.
Pow5:/sys/bus/vio/drivers/hvcs # ls
. .. 30000003 30000004 rescan
Firmware는 vty-server 수명과 partner vty 제거는 알리지만 partner 추가는 알리지 않습니다. HMC Super Admin이 partner 정보를 동적으로 추가했다면 `rescan`에 `1`을 써서 모든 server의 partner 정보를 갱신합니다. 읽은 값 `1`은 진행 중, `0`은 완료되었거나 실행된 적 없음을 뜻합니다.
Pow5:/sys/bus/vio/drivers/hvcs # echo 1 > rescan
Server entry 이름은 firmware가 만든 partition-unique 32-bit unit address입니다. 다음 예시는 제공되는 attribute를 보여 줍니다.
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # ls
. current_vty devspec name partner_vtys
.. index partner_clcs vterm_state
Pow5:/sys/bus/vio/drivers/hvcs/30000003 # cat name
vty-server
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat devspec
/vdevice/vty-server@30000004
`partner_vtys`와 `partner_clcs`는 같은 순서로 대응합니다. CLC는 system serial number, target partition을 나타내는 `-V*`, adapter slot을 나타내는 `-C*`로 구성됩니다.
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat partner_vtys
30000000
30000001
30000002
30000000
30000000
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat partner_clcs
U5112.428.103048A-V3-C0
U5112.428.103048A-V3-C2
U5112.428.103048A-V3-C3
U5112.428.103048A-V4-C0
U5112.428.103048A-V5-C0
| Attribute | 의미와 동작 |
|---|---|
| `index` | vty-server에 연결할 `/dev/hvcsN`의 N을 표시합니다. 핫플러그와 재부팅 뒤에는 다시 확인해야 합니다. |
| `vterm_state` | `1`은 연결됨, `0`은 연결되지 않음을 뜻합니다. 연결된 상태에서 `0`을 쓰면 수동으로 연결을 끊습니다. |
| `rescan` | 드라이버가 관리하는 모든 vty-server의 partner 정보를 firmware에서 다시 조회합니다. `1`을 쓰면 시작합니다. |
| `name` | 장치 유형인 `vty-server`를 반환합니다. |
| `devspec` | `/vdevice/vty-server@30000004` 같은 전체 device specification을 반환합니다. |
| `partner_vtys` | 연결 가능한 partner vty unit address 목록을 반환합니다. 주소는 partition 안에서만 고유하므로 반복될 수 있습니다. |
| `partner_clcs` | 각 partner vty에 대응하는 converged location code 목록을 같은 순서로 반환합니다. |
| `current_vty` | 현재 선택한 partner vty의 CLC를 표시하고, 유효한 CLC를 쓰면 다음 연결부터 대상을 바꿉니다. |
vty-server는 한 번에 하나의 vty에만 연결됩니다. `current_vty`에 유효한 partner CLC를 쓰면 target이 바뀌지만, 이미 열린 연결은 그대로 유지되고 현재 연결이 해제된 다음에 새 선택이 적용됩니다.
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # echo U5112.428.10304
8A-V4-C0 > current_vty
질문과 답변: 보안과 표시 문제
414-460HVCS의 주요 보안 고려 사항은 세 가지입니다.
- `/dev/hvcs*` node 소유자는 user/group 권한으로 접근을 제한해야 하며, console 접근 전용 `hvcs` group을 만드는 방법이 적절할 수 있습니다.
- Network를 통해 console-hosting partition에 들어갈 때는 SSH 같은 보안 연결을 사용하거나 물리 console에서 작업해야 합니다.
- 작업을 끝내면 console에서 logout해야 합니다. 그렇지 않으면 다른 partition에서 온 다음 연결이 이전 login session을 보게 됩니다.
여러 사람이 같은 console을 보도록 multiplex하려면 `screen`을 `/dev/hvcs*`에 직접 연결할 수 있습니다. 다만 기본 termcap 변환이 충분하지 않아 curses application 표시가 깨질 수 있습니다.
색상, control character, 출력이 깨지는 문제는 terminal conversion과 `$TERM` 불일치에서 생기는 경우가 많습니다. HMC의 `vt320` session이 먼저 로그인되어 있었을 수도 있습니다. Console을 얻은 뒤 현재 emulator에 맞는 `$TERM`을 export하고, 끊기 전에 `exit`하십시오.
질문과 답변: 연결 실패 진단
461-506`kermit`이 `/dev/hvcs*`를 열지 못하면 다음 원인을 순서대로 확인합니다.
- HMC 또는 다른 Power5 console mechanism이 target vty를 점유하고 있습니다. HMC에서 partition의 `close terminal`을 사용하거나 다른 console owner가 연결을 놓도록 해야 합니다.
- 현재 application 연결은 없지만 다른 사용자의 `vterm_state`가 아직 `1`입니다. Disconnection 절차로 server connection을 해제해야 합니다.
- 실행 user에게 `/dev/hvcs*` permission이 없습니다.
- `hvcs.ko`를 아직 넣지 않았지만 udev가 없는 system에서 오래된 node가 남아 있습니다.
- 존재하는 `/dev/hvcs*` node에 대응하는 vty-server device가 없습니다.
`UUCP lockfile directory`에 쓸 수 없다는 오류는 지정한 `/dev/hvcs*`가 실제 위치에 없거나, udev system에서 module을 아직 넣지 않은 상황일 수 있습니다.
질문과 답변: 설치·동시 연결·핫플러그
507-547이미 설치한 Linux partition의 `hvcs`를 두 번째 partition 설치 console로 사용할 수 있습니다. 단 `kermit`, `cu`처럼 terminal emulation을 하지 않는 program으로 연결해야 합니다.
여러 partition console에 동시에 연결하는 것도 가능합니다. Console-hosting partition에 여러 vty-server가 구성되어 있고 각각 연결되지 않은 vty를 가리켜야 합니다.
DLPAR와 hotplug가 enabled이고 kernel에 필요한 support가 포함되어 있으면 device의 동적 추가와 사용하지 않는 device의 제거를 처리합니다.
vty-server는 firmware가 노출하는 순서대로 `/dev/hvcs*`에 배정됩니다. 중간 slot에 hotplug server가 추가되면 module reload나 reboot 뒤 순서가 달라질 수 있으므로 `index` attribute로 항상 현재 mapping을 확인해야 합니다.
질문과 답변: Partition 사이 tty conduit
548-568Power5에서 target partition의 `hvc_console` driver는 추가 `/dev/hvc*` tty를 제공합니다. `/dev/hvc0`는 대개 console입니다.
HMC Super Admin이 target partition에 추가 `serial server`를 만들면 reboot 뒤 새 `/dev/hvc*`로 나타납니다. 이어 현재 partition에 `serial client`를 만들고 target의 새 server adapter와 slot을 가리키면 추가 `/dev/hvcs*`가 생깁니다.
그 뒤 target의 program은 `/dev/hvc*`, 현재 partition의 program은 `/dev/hvcs*`를 읽고 쓰도록 구성하여 두 partition 사이 tty conduit를 만들 수 있습니다.
HMC가 serial server/client partner를 구성하고 양쪽 tty node를 연결합니다.
버그 보고
569-581버그는 OS를 제공한 Linux distribution 회사에 보고하거나 PowerPC development mailing list `linuxppc-dev@lists.ozlabs.org`에 게시합니다.
공개 mailing list를 이용하면 이 드라이버의 문제와 해결책을 문서화하고 검색 가능한 형태로 남겨 모든 사용자가 활용할 수 있습니다.
요약과 해설
hvcs.rst:1-581HVCS는 firmware VTERM을 tty로 노출합니다. `/dev/hvcsN` 번호는 hotplug 뒤 바뀔 수 있으므로 sysfs `index`를 기준으로 찾고, data 유실을 피하려면 `vterm_state`로 명시적으로 연결을 해제해야 합니다.