요즘 X 서버는 연결된 모니터가 없고, /etc/X11/xorg.conf 파일에 수직/수평 주파수가 정의되어 있지 않다고 하더라도 일단 정상적으로 실행됩니다. 다만, 초기 해상도가 320×200 처럼 매우 작을 수 있습니다. 그런데 나중에 필요에 의해 모니터를 연결했는데 화면이 보이지 않는 경우가 발생합니다. 이 경우, 네트웍으로 접속해서 다음 명령어를 실행합니다.

$ export DISPLAY=:0.0
$ xrandr --auto

그러면 X 서버가 알아서 연결되어 있는 모니터를 출력으로 재설정하고 가장 선호하는(preferred) 해상도와 주파수를 선택합니다. 그런데 이를 자동으로 동작하게 하려면 udev 데몬의 도움을 받아야 합니다. 그래서 /etc/udev/rules.d 디렉토리에 확장자가 '.rules'인 파일을 생성하고 다음과 같이 내용을 채웁니다.

ACTION=="change", SUBSYSTEM=="drm", KERNEL=="card*", RUN+="/usr/bin/auto-xrandr.sh"

그리고 /usr/bin/auto-xrandr.sh 파일을 아래와 같이 작성한뒤 실행권한을 줍니다.

#!/bin/sh
[ "$DISPLAY" = "" ] && export DISPLAY=:0.0
xrandr --auto
xrandr --dpi 96

그러면 이제부터 모니터 연결시 자동으로 연결을 재설정하게 됩니다.

그런데, 만일 네트웍으로 접속했거나, udev 데몬에 의해 실행되는 경우 X 서버 인증이 안된 계정이라며 xrandr 명령이 실행이 거부됩니다. 이를 제대로 처리하려면 복잡한 인증 과정이 필요한데, 이를 쉽게 처리하려면 그냥 X 서버 시작할때 자동으로 실행되는 초기화 스크립트에 'xhost +' 명령어를 주면 인증을 무시하게 됩니다. 물론 보안상 좋은 방법은 아니지만, 폐쇠된 환경이라면 별로 문제가 없을 겁니다.

각각의 명령어에 대해 더 궁금하신 분은 관련 명령어 매뉴얼 페이지를 확인해 보시기 바랍니다.

참고로 조금만 더 설명하면, 노트북 외부 모니터 단자에 빔 프로젝트나 외부 모니터를 연결했을 경우도 xrandr 명령을 직접 사용하거나 지금까지 설명한 방법을 조금 다르게 응용할 수 있습니다.

이 글에서 소개하려는 eventfd()는 파이프 역할을 어느 정도 대체하기 위해 최근(?) 리눅스 커널에 추가된 API입니다. 읽고 쓰기에 각각 다른 두 개의 파일 디스크립터를 사용하는 파이프와 달리 eventfd는 한 개의 파일 디스크립터를 가지고 동시에 읽고 쓰기 작업을 처리합니다. 또한 별도 커널 버퍼와 복사 과정이 필요한 파이프와 달리 정수 값을 더하고(쓰고) 읽는 작업만 처리하기 때문에 성능도 훨씬 좋다고 합니다. 물론 파일 디스크립터이기 때문에 poll() 등과 함께 사용할 수 있습니다.

동작 방식을 간단하게 설명하면, write() 호출시 64비트 정수값을 쓰면 내부 버퍼 값에 더하면서, read() 호출시 내부 버퍼 값이 0일 경우 기다리다가, 값이 바뀌면 그 값을 읽어오고 0으로 초기화합니다.(세마포어 방식일 경우 1을 읽어오고 그 값에서 1을 감소합니다) 즉, 읽기 작업에 대한 poll() 호출은 내부 버퍼 값이 0일 경우 입력이 없는 것으로, 1 이상의 값일 경우 입력이 있는 것으로 간주하고 디스크립터를 감지하게 됩니다. (예제 코드는 매뉴얼 페이지에 포함된 코드를 확인하시길… 물론 예제 코드는 쓰레드간 통신에도 잘 동작합니다)

매뉴얼에 의하면 리눅스 커널 2.6.22, glibc 2.8 버전부터 eventfd() 함수를 지원합니다. 대부분의 요즘 리눅스 데스크탑 / 서버 배포판에서는 당연히 사용할 수 있지만 임베디드 시스템에서는 버전을 확인해야할 필요가 있습니다. 물론, eventfd가 메시지 내용 자체를 전송할 수 없다는 단점도 있지만, 이와 함께 리눅스 커널이 제공하는 signalfd(), timerfd(), epoll() 등을 함께 사용하면 고전 유닉스 프로그래밍의 한계에서 벗어나 마음껏 이벤트 기반 코드를 만들 수 있습니다.

물론 이미 잘 만들어진 GLib 메인루프나 libevent 등과 같은 라이브러리를 사용하는 것도 좋지만… :)

그런데 여담이지만, 아치리눅스 부팅 과정 커스터마이징과 속도를 경험해봐서 그런 건지, 범용 배포판은 어쩔 수 없이 모든 사용자가 만족할 수 있도록 가능한 많은 서비스 프로그램을 기본적으로 설치하고 이를 모두 시작하기 때문에 느려질 수 밖에 없는 건데, 부팅 속도 향상을 위해 시작 프로세스 관리 데몬의 성능과 기능을 개선하는 방향으로만 접근하고 있는 게 아닌가 하는 생각도 듭니다. 물론 다른 고급 기능을 제공한다고 하지만, 어차피 대부분의 기능은 배포판 개발자들만 사용하는 거고… :) 참고로, 이 발표자료만 봐도 부팅 속도와 초기화 프로그램의 능력은 무관한 것 같습니다.

아무튼, 지금까지 설명한 배경이 최근 임베디드 리눅스 컨퍼런스 2011 발표 슬라이드를 읽다가 PCD(Process Control Daemon)라는 프로세스 관리 데몬을 소개하는 내용을 보고 흥미를 가질 수 밖에 없었던 이유입니다. 위에 소개한 최신 프로그램들이 제공하는 기본 기능을 충실히 구현한 것은 물론, 임베디드 시스템을 우선 대상으로 개발했기 때문에 실행파일 크기가 매우 작고 빠르다는 점이 가장 매력적인 장점인 것 같습니다. (자세한 기능은 직접 확인해 보시길… :)

Systemd / Upstart 프로그램은 기능은 강력하지만 임베디드 시스템에 적용하기에는 너무 덩치가 크고 라이브러리 의존성도 무시하지 못할만큼 무겁습니다. 또한 임베디드 시스템은 개발자가 시스템의 모든 프로세스를 통제하고 완벽하게 관리해야 하기 때문에, 시스템에 대해 배포판 개발자와 동등하거나 더 많은 이해를 필요로 하므로 이러한 도구를 이용하면 작업이 수월해질 수 있습니다. 더 나아가, 이 프로그램을 조금 더 응용하면 데스크탑 / 서버용 시스템에서 여러 프로세스로 동작하는 시스템을 개발할 때도 유용하지 않을까 하는 생각도 듭니다.

물론 임베디드 리눅스 개발시 하나의 셸 스크립트 안에서 부팅 과정에 필요한 모든 작업을 처리하는 방식이 무조건 나쁜 건 아닙니다. 다만 복잡도가 더 높은 시스템을 설계할 때는 반드시 이런 프로세스 / 세션 관리 / 예외 처리 프로그램을 사용하거나 알아두면 나중에 참고하는 데 도움이 되지 않을까 생각해 봅니다.

내장 웹서버 라이브러리를 사용하면 얻을 수 있는 가장 좋은 장점은 MJPEG, RTSP-over-HTTP 등과 같은 웹기반 스트리밍 서버를 만들때 매우 편리하다는 점입니다. 한 프로세스 안에서 웹서버 + 스트리밍 생성 루틴이 함께 동작하므로 메모리 복사 오버헤드가 줄어들고 프로그래밍 복잡도 역시 감소합니다. 또한 CGI 프로세스가 따로 동작할 필요가 없으므로 웹을 통해 설정을 변경해도 별도의 프로세스간 통신이 불필요합니다.

물론, 내장 웹서버 방식이 장점만 있는 건 아닙니다. 기존 스탠드얼론 웹서버가 알아서 자동으로 해주던 부분, 예를 들어 디렉토리 인덱스 파일 생성, 동시 접속 클라이언트 수 관리, 클라이언트 캐시를 위한 수정 시각 고려 등을 프로그래머가 직접 작성해야 합니다. 특히 libmicrohttpd 라이브리는 GoAhead 등과 같은 상용 라이브러리에 비하면 자동화 부분이 조금 부족합니다. 예를 들어 파일 시스템의 일반 파일에 대한 웹서비스 처리도 직접 만들어야 합니다. 물론, 대부분 필요한 기능은 예제 소스를 참고하면 어렵지 않게 구현할 수 있습니다. 하지만 제 생각에는, 웹서버 라이브러리가 너무 많은 기능을 자동화하지 않는게 오히려 더 맞다고 생각하는데, 왜냐하면 대부분 응용 프로그램에서 웹서버를 내장하는 경우는 특수한 용도(RESTful / SOAP)이거나 필요한 기능만 구현하기 위해서이기 때문에 나머지는 모두 개발자가 제어하는게 라이브러리의 제 역할이 아닌가 생각합니다.

그런데, 요즘 기존 코드를 리팩토링하면서 가능한 오래된(?) 라이브러리에 대한 의존성을 없애고 있는데 위에서 설명한 작업을 하는 함수가 리눅스 기본 glibc 라이브러리가 당연히 제공하는 걸 알게 되어 잠시 허탈했습니다.

다음은 도메인 이름을 인수로 주면 해당 도메인의 MX 레코드, 즉 메일서버 호스트를 glibc API를 이용해 작성한 코드입니다.

#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>
 
static char *
lookup_mx (const char *name)
{
  unsigned char response[NS_PACKETSZ];  /* big enough, right? */
  ns_msg        handle;
  int           ns_index;
  int           len;
 
  len = res_search (name, C_IN, T_MX, response, sizeof (response));
  if (len < 0)
    {
      /* failed to search MX records */
      return strdup (name);
    }
  if (ns_initparse (response, len, &handle) < 0)
    {
      /* failed to parse MX records for '%s'", name); */
      return strdup (name);
    }
  len = ns_msg_count (handle, ns_s_an);
  if (len <= 0)
    {
      /* no mx records */
      return strdup (name);
    }
  for (ns_index = 0; ns_index < len; ns_index++)
    {
      ns_rr rr;
      char  dispbuf[4096];
 
      if (ns_parserr (&handle, ns_s_an, ns_index, &rr))
        {
          /* WARN: ns_parserr failed */
          continue;
        }
      ns_sprintrr (&handle, &rr, NULL, NULL, dispbuf, sizeof (dispbuf));
      if (ns_rr_class (rr) == ns_c_in && ns_rr_type (rr) == ns_t_mx)
        {
          char mxname[MAXDNAME];
 
          dn_expand (ns_msg_base (handle),
                     ns_msg_base (handle) + ns_msg_size (handle),
                     ns_rr_rdata(rr) + NS_INT16SZ,
                     mxname,
                     sizeof (mxname));
          return strdup (mxname);
        }
    }
  return strdup (name);
}

관련 자료는 Stack Overflow에서 본 것 같기도 하고… 아무튼, 명색이 전문 리눅스 C 프로그래머로서 15년 넘게 버티고 있으면서도 아직까지도 기본 C 라이브러리가 제공하는 함수도 제대로 알지 못하는 스스로를 돌아보게 됩니다. :(

이러한 udev 서브 시스템의 혜택을 개발자가 얻기 위해 많은 방법이 존재하지만, 이 글에서는 GLib 메인루프 기반으로 동작하는 GUDev 라이브러리를 이용하는 법을 설명합니다. GLib 라이브러리를 사용하지 않을 경우 직접 libudev 라이브러리를 사용해도 되지만, 기본 개념만 파악하면 쉽게 어떤 라이브러리를 사용해도 상관없기 때문에 인터페이스가 더 편하고 직관적인 GUDev 라이브러리를 사용합니다. 참고로, 이 글은 “libudev and Sysfs Tutorial” 글과 “gudev Vala bindings” 글을 참고했습니다.

먼저 라이브러리를 설치하려면 우분투에서는 libgudev-1.0-dev 패키지, 아치리눅스에서는 udev 패키지를 설치하면 됩니다. (여담이지만, 아치리눅스는 개발에 필요한 헤더파일과 라이브러리가 별도 패키지로 분리되어 있는 경우가 별로 없는 것 같습니다)

다음 소스 코드는 현재 시스템에 장착된 모든 블럭 장치(block)를 보여주고, 이후 USB 플래시가 삽입되거나 제거되었을때 이를 감지하여 표시하도록 한 소스 코드입니다.(gudev.c)

#include <gudev/gudev.h>
 
static void
print_device (GUdevDevice *device)
{
  const gchar * const *symlinks;
 
  g_print ("  subsystem       : %s\n"
           "  devtype         : %s\n"
           "  name            : %s\n"
           "  number          : %s\n"
           "  sysfs_path      : %s\n"
           "  driver          : %s\n"
           "  action          : %s\n"
           "  seqnum          : %lld\n"
           "  device_type     : %d\n"
           "  device_number   : %d\n"
           "  device_file     : %s\n"
           "\n",
           g_udev_device_get_subsystem (device),
           g_udev_device_get_devtype (device),
           g_udev_device_get_name (device),
           g_udev_device_get_number (device),
           g_udev_device_get_sysfs_path (device),
           g_udev_device_get_driver (device),
           g_udev_device_get_action (device),
           g_udev_device_get_seqnum (device),
           g_udev_device_get_device_type (device),
           g_udev_device_get_device_number (device),
           g_udev_device_get_device_file (device));
}
 
static void
uevented (GUdevClient *client,
          gchar       *action,
          GUdevDevice *device,
          gpointer     user_data)
{
  g_print ("[action:%s]\n", action);
  print_device (device);
}
 
static void
print_block_device (gpointer data,
                    gpointer user_data)
{
  GUdevDevice *device = data;
 
  print_device (device);
  g_object_unref (device);
}
 
static void
print_block_devices (GUdevClient *client)
{
  GList *devices;
 
  devices = g_udev_client_query_by_subsystem (client, "block");
  if (devices)
  {
    g_print ("[block devices]\n");
    g_list_foreach (devices, print_block_device, NULL);
    g_list_free (devices);
  }
}
 
int
main (int    argc,
      char **argv)
{
  const gchar *subsystems[4] =
    { "usb/usb_interface", "scsi/scsi_device", "block", NULL };
  GUdevClient *client;
  GMainLoop   *main_loop;
 
  g_type_init ();
  main_loop = g_main_loop_new (NULL, FALSE);
 
  client = g_udev_client_new (subsystems);
  g_signal_connect (client, "uevent", G_CALLBACK (uevented), NULL);
 
  print_block_devices (client);
 
  g_main_loop_run (main_loop);
  g_object_unref (client);
 
  return 0;
}

컴파일 하려면 다음과 같이 실행하면 됩니다.

$ gcc -o gudev gudev.c `pkg-config --cflags --libs gudev-1.0`

소스 코드를 간단하게 설명하면, 제일 먼저 g_udev_client_new() 함수를 이용해 GUdevClient 객체를 생성합니다. 이때 넘겨주는 인수는 변화를 감지하고 싶은 서브 시스템 목록인데, 여기서는 모든 블럭 장치와 USB, SCSI 서브 시스템을 지정했습니다.(SCSI는 실제로 모든 종류의 하드디스크를 의미하기도 합니다) 만일 NULL을 지정하면 변화 감지 기능을 사용하지 않고 그냥 질의(query) 계열 API만 사용할 수 있으며, 비어있는 목록을 넘겨주면 시스템의 모든 서브시스템의 장치 변화를 감지해서 시그널로 알려줍니다. 참고로 매뉴얼에는 클라이언트를 생성한 쓰레드의 메인루프를 사용하여 감지 루틴이 실행된다고 하니, 만일 별도 쓰레드에서 이 감지 작업을 수행하려면 쓰레드를 먼저 만들고 그 쓰레드 안에서 생성해야 합니다. 이 예제에서는 테스트를 위해 기본 메인 루프를 사용하고 있습니다.

직접 장치 목록을 질의(query)하거나 시그널이 발생했을 경우 넘겨받는 GUdevDevice 객체와 g_udev_device_get_*() 계열 API를 이용하면 장치의 세부 정보를 얻을 수 있습니다. 위 예제에서는 udev / sysfs 관련 속성 등은 출력하지 않고 있지만, 필요하다면 더 자세한 정보를 얻을 수 있습니다.

실행하면 대략 다음과 같이 출력됩니다. (당연히 실행 환경에 따라 결과가 다릅니다)

$ ./gudev
[block devices]
  subsystem       : block
  devtype         : disk
  name            : sda
  number          : (null)
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
  driver          : (null)
  action          : (null)
  seqnum          : 0
  device_type     : 98
  device_number   : 2048
  device_file     : /dev/sda
 
  subsystem       : block
  devtype         : partition
  name            : sda1
  number          : 1
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1
  driver          : (null)
  action          : (null)
  seqnum          : 0
  device_type     : 98
  device_number   : 2049
  device_file     : /dev/sda1
 
  subsystem       : block
  devtype         : disk
  name            : sr0
  number          : 0
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1f.2/host5/target5:0:0/5:0:0:0/block/sr0
  driver          : (null)
  action          : (null)
  seqnum          : 0
  device_type     : 98
  device_number   : 2816
  device_file     : /dev/sr0

위 출력에서는 일반 디스크 장치(/dev/sda)와 디스크 파티션(/dev/sda1), DVD-RW 장치(/dev/sr0)가 있음을 보여줍니다. 여기서 만일 일반 USB 플래시 메모리를 삽입하면 다음과 같은 결과가 출력됩니다.

[action:add]
  subsystem       : usb
  devtype         : usb_interface
  name            : 2-3:1.0
  number          : 0
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0
  driver          : usb-storage
  action          : add
  seqnum          : 1934
  device_type     : 0
  device_number   : 0
  device_file     : (null)
 
[action:add]
  subsystem       : scsi
  devtype         : scsi_device
  name            : 17:0:0:0
  number          : 0
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/host17/target17:0:0/17:0:0:0
  driver          : sd
  action          : add
  seqnum          : 1938
  device_type     : 0
  device_number   : 0
  device_file     : (null)
 
[action:change]
  subsystem       : scsi
  devtype         : scsi_device
  name            : 17:0:0:0
  number          : 0
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/host17/target17:0:0/17:0:0:0
  driver          : sd
  action          : change
  seqnum          : 1944
  device_type     : 0
  device_number   : 0
  device_file     : (null)
 
[action:add]
  subsystem       : block
  devtype         : disk
  name            : sdc
  number          : (null)
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/host17/target17:0:0/17:0:0:0/block/sdc
  driver          : (null)
  action          : add
  seqnum          : 1945
  device_type     : 98
  device_number   : 2080
  device_file     : /dev/sdc
 
[action:add]
  subsystem       : block
  devtype         : partition
  name            : sdc1
  number          : 1
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/host17/target17:0:0/17:0:0:0/block/sdc/sdc1
  driver          : (null)
  action          : add
  seqnum          : 1946
  device_type     : 98
  device_number   : 2081
  device_file     : /dev/sdc1

위 예제 소스 코드에서 감시하기 위해 지정한 서브 시스템 모두의 변화를 보여주다보니 복잡해 보이지만, 결국 USB 플래시 메모리가 USB / SCSI / BLOCK 서브시스템에 모두 정상적으로 감지되는 걸 확인할 수 있습니다. 다시 장치를 제거하면 다음과 같이 출력됩니다.

[action:remove]
  subsystem       : block
  devtype         : disk
  name            : sdc
  number          : (null)
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/host16/target16:0:0/16:0:0:0/block/sdc
  driver          : (null)
  action          : remove
  seqnum          : 1926
  device_type     : 0
  device_number   : 2080
  device_file     : /dev/sdc
 
[action:remove]
  subsystem       : scsi
  devtype         : scsi_device
  name            : 16:0:0:0
  number          : 0
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/host16/target16:0:0/16:0:0:0
  driver          : (null)
  action          : remove
  seqnum          : 1927
  device_type     : 0
  device_number   : 0
  device_file     : (null)
 
[action:remove]
  subsystem       : usb
  devtype         : usb_interface
  name            : 2-3:1.0
  number          : 0
  sysfs_path      : /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0
  driver          : (null)
  action          : remove
  seqnum          : 1931
  device_type     : 0
  device_number   : 0
  device_file     : (null)

이 정보를 실제로 어떻게 활용할지는 이제 어플리케이션에게 달린 몫입니다.

아무튼 요즘은 윈도우나 맥 부럽지 않은 리눅스 사진 관리 프로그램들이 많이 있어서 편하긴 한데, 이런 프로그램들이 존재하기 전부터, EXIF 정보가 포함되지도 않았던 시절부터 디렉토리별로 관리해오던 습관을 버리지 못하는 게 문제입니다. 예를 들어 폴더는 알아보기 쉽게 YYYYMMDD-장소또는이벤트이름 식으로 이름짓고, 안에 들어있는 JPEG 파일은 YYYYMMDD-hhmmss-photo.jpg, 동영상 파일은 YYYYMMDD-hhmmss-movie.mp4 식으로 이름을 지어 줍니다.

물론, 이런 작업을 모두 수작업으로 하지는 않습니다. EXIF 정보에 문외한이던 시절에는 gthumb 같은 프로그램의 이름일괄변경(Rename...) 기능을 이용해 자동으로 날짜 뒤에 일련번호를 붙이기도 했습니다.

하지만 요즘은 그것도 귀찮아서 exiv2 / rename 명령어를 이용해 한꺼번에 변경해 버립니다. exiv2 프로그램을 이용해 EXIF 정보에 들어있는 촬영 시각을 기준으로 사진 파일 이름을 변경하고,  rename 명령어를 이용해 대문자로 된 .JPG 확장자를 소문자 .jpg 확장자로 한번에 변경합니다. 예를 들어 위에서 설명한 예처럼 파일 이름을 변경하려면 사진 파일이 들어 있는 디렉토리에서 다음과 같이 실행하면 됩니다.

$ rename .JPG .jpg *.JPG
$ exiv2 -r '%Y%m%d-%H%M%S-photo' -k rename *.jpg

rename 명령어는 대부분 배포판에 기본으로 설치되어 있으나 exiv2 프로그램은 수동으로 패키지를 설치해야 할 수도 있습니다. 게다가, 우분투의 rename 명령어는 perl 패키지에 포함되어 있는 버전인데 아치 리눅스는 util-linux 패키지에 포함되어 있는 거라 사용법이 조금 다릅니다. 참고로 위 예제는 아치 리눅스 버전입니다. 하지만 exiv2, rename 명령어 모두 매뉴얼 페이지를 보면 자세한 사용 예제가 있으므로 쉽게 사용할 수 있습니다.

그리고 이 글은 사실, 나이가 들수록 자꾸만 옵션을 잊어버려 다시 찾기 귀찮아서 기록하고 있습니다… :)

그렇다고 데비안이나 페도라, 젠투 배포판으로 가기에는 별로 재미가 없을 것 같아서 여기 저기 확인해보다가 아치 리눅스를 선택하게 되었습니다. 여러가지 이유가 있지만, 32비트 버전의 경우 패키지 바이너리가 i686에 최적화되어 있고, 패키지 시스템이 의외로 빠르고 단순명료하게 동작하면서, 6개월마다 시스템을 갈아 엎을 일 없이 계속 조금씩 업그레이드 되어(rolling release) 최신 소프트웨어를 항상 바로 사용할 수 있다는 점이 맘에 들었습니다. 더 이상 우분투 개발 버전을 사용하면서 X가 실행되지 않는다든지, 부팅이 안된다든지, 잘 돌던 소프트웨어가 동작하지 않는다든지 걱정할 필요가 없어진 셈입니다. 게다가 아치 사용자 저장소(Arch User Repository; AUR)와 yaourt 프로그램을 사용하니 기존에 별도로 설치했던 dropbox, android-sdk, eclipse, openproj 등도 쉽게 패키지로 설치할 수 있어 더 편했습니다. 물론 GUI 방식 패키지 관리자가 없고 패키지 설치만으로 모든 설정이 자동으로 되는게 아니라 어느 정도 리눅스 경험자가 아니면 불편한 점도 많지만, 오히려 중급 사용자 이상일 경우 원리를 하나씩 알아가면서 설치하는 재미도 쏠쏠합니다. 게다가 별도 문서가 불필요할 정도로 아치리눅스 위키 페이지 정리가 잘 되어 있어 굳이 다른 구글링도 필요없는 것 같습니다. 물론, 한글 글꼴 패키지의 부족이나 부족한 그놈 테마 패키지 등 못마땅한 점이 없는 건 아니지만, 어차피 단점 없는 배포판은 없는 법, 나름 오랜만에 커스터마이징에 즐거운 시간을 보낸 것 같습니다.

인증 스크린샷이라도 하나 올리려다가, 별로 다른게 없어서 그만 두었습니다. 사용하는 배포판이 무엇이든, 어차피 설치 이후에는 결국 동일한 리눅스일 뿐이기 때문입니다. 여담이지만, 오래된 저사양 노트북에서도 동일한 그놈 환경인데 우분투보다 더 빨리 실행되는 듯한 느낌을 받고 있습니다. 물론 정신적인 영향이 더 큰 것 같기도 하지만… :)

그런데, 최근 리눅스 커널과 배포판에는 perf 추적(trace) 도구가 포함되어 있습니다. 그리고 이를 기반으로 한 여러 명령어 중에서, 이 글에서 소개하는 perf top 명령어를 사용하면 쉽게 현재 실행중인 커널 / 사용자 프로세스의 CPU 사용 내역을 확인할 수 있습니다. 이 명령어는 기본적으로 top 명령어와 비슷하게 동작하지만, OProfile 같은 도구처럼 별도의 복잡한 설정 과정이 필요없다는 장점이 있습니다. 게다가 그 원리를 조금만 이해하면 다양한 응용이 가능하고, 최근 리눅스 커널에 추가된 많은 추적 도구 중에서 가장 활발하게 개발되고 있는 프레임워크이기 때문에 익숙해지는 것도 나쁘지 않을 것 같습니다.

우분투 리눅스에서 perf 도구를 사용하려면 제일 먼저 다음과 같이 해당 패키지를 설치해야 합니다.

$ sudo apt-get install linux-tools

실행하기 위해서 반드시 perf 이벤트 접근 권한이 있어야 하므로 루트 계정 또는 sudo 명령을 이용해 다음과 같이 무작정 실행하면 됩니다.

$ sudo perf top

위 출력 화면을 간단하게 설명하면, 마지막 갱신 주기 동안 AES_encrypt 함수가 가장 많이 실행되었습니다. 목록은 위에서 아래로 더 많이 실행된 순서로 정렬되어 있는데, 각 열(column)을 설명하면, 맨 앞의 샘플(samples)과 퍼센트(pcnt)는 총 성능 카운터 샘플링 중에서 차지한 회수와 비율을 나타내고 함수(function)과 동적 공유 객체(DSO)는 샘플링된 위치를 보여줍니다. 따라서 가장 많이 샘플링된 함수가 갱신 주기 동안 가장 많이 실행된 부분이라고 해석하면 됩니다.

예를 들어 위 실행 결과는, git pull 명령으로 ssh 방식 네트웍 서버로부터 데이터를 받아오는 작업을 처리하는 과정을 분석한 것입니다. ssh 연결이므로 암호화 관련 라이브러리 호출이 가장 많이 보이고, 커널에서 사용자 공간으로 복사하는 함수, e1000 이더넷 드라이버 인터럽트 핸들러 등이 눈에 띕니다.

man perf top 또는 perf top help 명령으로 더 자세한 사용법을 얻을 수 있습니다. 많은 옵션이 있지만 그 중에서 자주 사용하는 옵션 몇 가지만 설명하면, -v 옵션은 함수 내에서 더 장확한 샘플링 위치를 보여주면서 상세한 메시지를 출력합니다. 그리고, -s 옵션은 지정한 함수만 어셈블리 단계에서 샘플링한 결과를 자세히 보여줍니다.

참고로, 데비안 / 우부툰에서 개발하는 분이라면 패키지로 설치한 라이브러리의 디버깅 심볼 포함 패키지를 함께 설치해 두면, 예를 들어 libc6 라이브러리는 libc6-dbg 패키지(끝에 ‘-dbg’가 더 붙음), 많은 개발 / 분석 도구에서 더 자세한 정보를 얻을 수 있습니다.