Alpha Linux
설치와 활용 Alpha Linux
설치와 활용
한동훈
참고 사항 : |
이 글은 리눅스 월드 '98년
2월호 기사이다. |
알파...
아마도 리눅스 사용자면 하나쯤
가지고 싶은 시스템일 것이다. 오죽하면 총각 리눅서가 바라는 혼수용품 목록
1호에 올랐을까? :)
작년에 우리나라를 방문했던 존 매드독 홀씨는 국제리눅스협회일 외에 디지털 사의 알파 리눅스 지원 창구역을 맡았다고 이야기하면서, 자신과 리누즈 토발즈 사이에 있었던 알파 리눅스 개발 계기와 관련된 재미있는 에피소드를 들려주었다. 매드독씨와 토발즈군이 함께 만나 뱃놀이를 하면서 이야기를 나누던 중, 알파 리눅스 포팅에 대해서 어떻게 생각하느냐고 매드독씨가 질문하자. 토발즈군은 알파에 대해서는 달리 생각해본 바가 없고, 파워PC에서의 리눅스 포팅을 생각하고 있다고 답변했다. 이에 놀란 매드독씨는 자신이 근무하는 디지털 사를 통해 알파 시스템을 토발즈에게 기증하고, 포팅을 위해 필요한 인원을 지원했다는 이야기를 꽤 우스광스러운 표정으로 들려주던 기억이 난다.
아뭏던 이렇게 해서 포팅은 시작되었고, 이제
알파에서도 안정적인 리눅스 시스템을 구경할 수 있게 되었다.
그렇다. 예전에 처음으로 알파 리눅스 커널이 나올 때는 32비트 였다. 이때는 디지털 사에서 인텔 리눅스와 동일한 테이터 타입을 사용하여 포팅하였으며, 소스 코드를 리눅스 공동체에 기부하였다.
알파 리눅스 홈페이지
이때 나온 알파 리눅스 커널 1.0은 ECOFF 라는 특이한 목적 파일 포맷을 가지고 있어서, 실행 파일의 크기가 장난이 아니였다고 한다. 이후에 리누스는 매드독씨를 만나게 되고, 그에게서 Jensen 머쉰(알파 계열의 일종)을 빌려서, 포팅 작업을 시작하게 된다.
1994년 10월 24일, 커널 버전 1.1.60에 드디어 include/asm-alpha 디렉토리가 커널에 추가되었다. 이때 리누스는 알파 리눅스 커널을 만들기 위해 goc를 사용하지 않고, 알파 리눅스에서 전혀 수정할 필요가 없었던 디지털 유닉스에 있던 컴파일러를 사용했었다. gec 가 아직 리눅스 포팅이 되기 전의 일이었다. 같은 시간에 디지털사의 리눅스 지원팀에서는 Xfree86이 제이 이스타브룩(Jay Eastabrook)에 의해 포팅되었고, MILO 부트로더가 데이브 러슬링(Dave Rusling)에 의해 작성이 완료되어서, 64-bit 리눅스의 기본 설치에 필요한 작업들이 일차적으로 마무리 되었다. 이들은 다시 외부에서 지원자를 받게 된다. 여기에는 C 라이브러리를 64비트로 포팅한 밥 맨슨(Bob Manson)과 여러 확장 시스템을 개발한 데이비드 모스버거탕(David Mosberger-Tang)이 포함되어 있었다. 마침내 시간은 흘러 커널 버젼이 1.2로 올라가게 되고, 런타임 라이브러리와 GNU 개발 툴이 완벽한 64비트에서 수행되었다.
처음에 알파 리눅스의 바이너리 형식은 ECOFF 였지만, 1996년 7월을 기해 GNU libc에 기반한 ELF 시스템으로 전면 전환하여 공유 라이브러리를 자연스럽게 사용할 수 있었다.
디지털에서 처음에 내어 놓은 리눅스 배포본의 이름은 브레이드(BRADE) 였다. 이것은 그다지 사용되지 않아서 사람들의 관심에서 멀어져 갔으며, 이를 개발한 디지털은 자신들이 개발한 소스를 리눅스 배포본에 넣기를 원치 않았다. 지금은 익히 알고 있는 레드햇과 크래프트워크(Craftwork)에서 상용 알파 리눅스 배포본을 판매하고 있다.
알파 리눅스는 RISC 아키텍쳐에서 돌아가는 완벽한
64비트 운영체제이다. 이제 리눅스를 소개할 때 사용되는 "32비트 운영체제"라는
말은 수정될 필요가 있다.
알파는 Digital Equipment Corporation의 알파 프로세서 시리즈이다. 알파 CPU는 일반적인 인텔 CPU 의 CISC 아키텍쳐가 아닌, 조금 다르지만 약간 진보적인, 완전한 RISC 64비트 프로세서이다. 92년에 처음으로 21064 계열의 150MHz가 나타난 데 이어 현재에는 21164 600MHz 까지 출시되었다. 조만간 21264 계열로 옮아가면서 GIGA MHz를 넘어서 끝도 없이 속도 높이기로 나아갈 것 같다. 현재 가까이서 접할 수 있는 PC 서버급의 알파 시스템은 21164 466-533MHz를 탑재한 PC164LX와 21164PC 기종을 탑재한 PC164SX등이 있으며 곧 이어 나올 것으로 보이는 UX, ZX 등도 곧 접할 수 있을 것 같다. 이외에도 디지탈사에서 판매하는 고가의 본격 워크스테이션급의 머쉰들도 다수 있다.
현재, 알파에서 돌아가는 OS는 Linux, windows
NT, DEC UNIX, Open/VMS 가 있지만 모든 시스템에서 돌아가는 것은 아니다. DEC
UNIX 는 기종에 따라 다르며 필자는 Open/VMS를 구경도 해 본 적이 없다. 결론적으로
많이 사용되기는 Linux , NT정도라고 보면 될 것이다.
▶AlphaPC64 (Cabriolet, Aspen Telluride) ▶AxpPCI33 (Noname) ▶EB64++ (Aspen Alpine) ▶EB66 (Neko Tech Mach 1) ▶EB66+ ▶Jensen (DEC PC 150, 2000 model 300, Cullean) ▶Universal Desktop Box (UDB, Multia 라고도 부름). ▶AlphaStation 200, 250, 255, 400 (Avanti machines) ▶EB164 (Aspen Avalanche, Timberline, Summit; Microway Screamer) ▶Kinetics 에서 나온 Platform 2000머쉰 ▶PC 164 머쉰 (Durango) ▶Alcor 타입 머쉰 (AlphaStation 500, 600; Maverick, Brett) ▶Alpha-XL ▶Alpha-XLT (XL 300, XL 366) ▶AlphaPC164LX ▶AlphaPC164SX (Montrose)
PC164LX와 PC164SX는 최근에 나온 기종이라서
레드햇 5.0부터 지원된다. 하지만 MILO 이미지만 추가로 들어 있는 것 빼고는
시스템 아키텍쳐 면에서 특별히 달라진 것은 없으므로 4.2버젼을 NCR 850,
BusLogic PCI, Adaptec AHA2940 계열, Qlogic방식의 Digital 제품이 무난하고,
3Com, NE2000호환 랜카드도 잘 돌아간다. 그래픽 카드는 일반적인 S3 칩이
무난하고, 밀리니엄 MGA2 가 래드햇 5.0부터 돌아간다는 것을 제외하고는
인텔 리눅스와 거의 동일하다.
알파 리눅스에서는 LILO를 사용하지 않는다. 인텔 구조와 알파 구조가 다르기 때문이다. 인텔 구조에서는 부팅하면 바이오스를 읽어들이고, 커널 로더를 읽기 위해 첫번째 하드 디스크의 첫부분이나 플로피를 읽어들이지만, 알파 구조에서는 부팅하면 EEPROM(Flash ROM)에서 펌웨어를 읽어 들인다. 모든 것은 이 펌웨어에서 결정된다.
이것을 알파 바이오스라고도 하는 데, 한가지 주의할 점은 기본 알파 바이오스는 NT 바이오스로서 NT 설치의 편리성을 제공하기 위한 목적으로 설계되어 있어서, 리눅스 사용자에 대한 배려가 없다는 점이다. 이점이 디지탈의 마케팅 전력을 읽을 수 있는 지점이 아닐까 생각한다. 리눅스 공동체에 대한 지원을 간헐적으로 하면서도 자사의 머쉰에서 NT만큼이나 많은 사용자들이 리눅스를 사용하고 있음에도 불구하고, NT만을 배려하는 것은 그리 공평한 처사가 아니라고 본다. 어찌되었는지 다들 MS사의 마케팅을 대신 해주지 못해 안달인 것 같아 씁쓸한 마음을 지울 수 없다. 조금 옆길로 샛지만 어쨌든 알파에서 리눅스를 부팅하는 방법에는 여러가지가 있다.
☞ MILO 이미지 : MILO(MiniLoader)는 알파
리눅스를 적재하는 역할을 하며, 다른 OS를 적재할 수는 없다. MILO는 비압축
및 압축커널, ECOFF 및 EFL 포맷의 커널을 모두 적재할 수 있다. 또한 네트웍을
제외한 모든 장치에서 커널을 읽어들일 수도 있다. MILO 는 자신을 Flash
메모리에 자신을 적재하고, 커널을 수행하기 전에 메모리에서 자신을 제거한다.
MILO 플로피를 만들기 위해서는, 리눅스나 디지털 유닉스 시스템에서 dd 명령을 사용하거나, 마이크로소프트 윈도우즈 NT 나 MS-DOS 시스템에서 레드햇 시디에 들어있는 rawrite.exe프로그램을 사용할 수 있다. dd를 사용하려면, 먼저 CD 를 마운트하고 (/mnt/cdrom 에 마운트하는 것으로 가정하겠다). milo/image/ 에서 여러분의 시스템에 맞는 이미지를 선택한다. 몇몇 최신기종의 MILO 이미지는 레드햇 4.2에 없으므로 5.0 시디에서 구하던지, 아니면 레드햇 미러링 사이트에서 alpha MILO 를 구할 수 있다.
여기에는 항상 최근의 MILO 이미지가 올라온다. FAT으로 포맷된 플로피에 여기에서 구한 milo 이미지와 CDROM에 있는 linload.exe를 복사해서 넣으면 된다.
레드햇 사이트와 레드햇의 미러링 사이트에는 최신 버젼이 있는 디렉토리에 항상 milo 이미지가 비교적 새로운 것이 들어있다. MILO 이미지를 만들려면 다음과 같은 명령을 사용한다.
rawrite 를 사용하려면, 여러분의 시스템에 맞는 적당한 이미지를 선택한 다음, 다음과 같이 사용한다. (시디롬 드라이브가 d: 라고 가정한다.)
rawrite 는 먼저 디스켓 이미지 이름을 물어볼 것인데, 여기에서 여러분의 시스템에서 사용할 MILO 이미지의 이름을 입력한다. (예 : lx164.img). 그리고 이미지를 쓸 디스켓 드라이브를 물어보면 a: 하고 입력한다.
이후에 설치 시에 MILO가 제대로 되지 않는다면,
자신의 시스템에 MILO 이미지가 정확히 맞지 않아서 일 가능성이 높다. 이럴때는
MILO 이미지를 새로운 버젼으로 교체한다던지 SRM 콘솔에서 aboot을 사용하는
방법은 비교적 까다롭기 때문에 신중하게 최후의 수단으로 선택하길 바란다.
"MILO 이미지" 라고 라벨을 붙여두고 잘 보관하도록 하자.
MILO 플로피 디스크를 만든 후에, 자신의 시스템 타입에 맞는 적당한 Linux/Alpha커널이 들어가는 부트 플로피를 만들어야 한다. 커널 이미지는 레드햇 CD의 images/디렉토리에 들어있다.
이들 이미지에서 일반적인 VGA나 TGA에 기반한
그래픽 카드들이 잘 돌아간다.
커널 플로피를 만들기 위해서는 앞서와
마찬가지로 dd나 rawrite를 사용하면 된다.
예를 들어, (Linux 나 UNIX
상에서) dd를 사용해 보이도록 하겠다.
(윈도우 NT 나 MS-DOS 에서) rawrite 를 사용하셔도 무방하다.
rawrite 를 실행하면, 먼저 디스켓 이미지
이름을 물어오는 데 시스템에서 사용할 커널 이미지의 이름을 입력한다.
(예 : lx164.img). 그리고 이미지를 쓸 디스켓 드라이브를 물어보는 데,
일반적으로 a: 를 입력하면 된다.
"알파 리눅스 커널 플로피"
라고 라벨을 붙여 두도록 하자.
☞ PC164LX 와 PC164SX의 경우에 적당한 커널 이미지가 없다면 eb164.img 을 사용하면 무난하게 설치할 수 있다. 이때에는 시스템 타입이 정확하게 맞지 않기 때문에 약간의 문제가 발생할 수 있으므로 설치후 커널을 재컴파일하기 바란다.
램디스크 이미지는 레드햇 CD 의 images/ramdisk.img.이다. 램디스크 이미지도 MILO 플로피나 부트 플로피를 만들 때와 마찬가지로 dd나 rawrite를 사용하여 만들면 된다. (Linux 나 UNIX상에서) dd를 사용한다면...
rawrite를 사용한다면
rawrite 는 디스켓 이미지 이름을 물어보는데,
ramdisk.img를 입력한다. 그리고 이미지를 쓸 디스켓 드라이브를 물어보면,
일반적으로 a: 라고 입력하면 된다.
"램디스크 플로피" 라고
라벨을 붙여두자.
알파에서는 디스켓만 집어넣는다고 부팅되는 것은 아니다. 부팅을 위해서는 바이오스를 제대로 설정해야 한다. 부팅 시의 처음에는 그래픽 카드에 대한 정보를 보여주고, AlphaPowered라는 문구와 함께 못생긴 컴퓨터 그림이 하나 나온다. 그 다음에는 각종 장치를 찾아내어서 초기화 하는 과정에 들어간다. 필자가 사용하고 있는 시스템은 Digital Alpha 21164 533Mhz와 AlphaPC164LX 이다. 화면에 나타나는 메세지는 다음과 비슷할 것이다.
AlphaBIOS 5.62-1a
Alpha Processor and system Information System: AlphaPC 164LX Processor: Digital Alpha 21164, 533MHz Memory: 128MB SCSI Controller Initialization ... Initializing ATAPI #0 ... Device: Disk SCSIID: 0 QUSNTUM FIREBALL SE4 API. Initializing ATAPI #1 ... Device: CD-ROM SCSIID: 0 GoldStarCD-ROM CRD-8240B1.10 Network Initialization ... Initilization ... NETWORK HARDWARE HOST IP SERVER IP 0 00-40-05-36-14-52 0.0.0.0 0.0.0.0 Initalizing Complete. F2=SETUP PATUS=Pause Display ESC=Bypass Network Init
초기화 과정이 끝나고 나면, 선택 메뉴로 들어간다. 설치가 완료된 필자의 시스템에서는 다음과 같다.
AlphaBIOS Version 5.62 -1a Please select the operating system to start: Windows NT Workstation Version 4.00 Linux Use ↑ and ↓ to move the highlighto you choice Press Enter to choose. Pressto enter SETUP
우리는 아직 설치를 하지 않았기 때문에
아무런 메뉴가 나타나지 않는다.
이제 Linux 부팅 설정을 위해서 'Utilities'메뉴의 'OS selection Setup...' 메뉴로 들어가보자. 아무런 선택 메뉴 항목이 없거나 있더라도 Windows NT 메뉴가 하나 달랑 있을 것이다. 없으면 메뉴를 새로 하나 만들고, 설치하지 않는 OS 의 메뉴가 있다면 수정을 선택해서,
Boot Name: Linux Boot File: A: \linload.exe OS Path : CD: \milo OS Options
이렇게 편집해 보자. Boot Name 은 자기 마음대로 지정해도 상관없다. OS Options는 이후에 MILO 에서 리눅스 커널을 자동으로 읽어들이도록 설정하는 데 사용하면 유용하다. 지금은 그냥 넘어가자. 이제 변경된 내용을 저장하고, 빠져나와서 재부팅을 시키자. 바이오스의 내용이 변경하고 나서 재부팅을 하지 않으면 리눅스로 부팅이 되지 않으므로 주의하는 것이 좋다. 이제 Linux 라는 OS 부팅 메뉴가 하나 생겼을 것이다.
이제 MILO 디스크를 끼워넣고, 엔터키를 누르면 펌웨어에서 MILO 를 읽어들이면서 화면이 바뀐다. 아무런 이상이 없다면 MILO> 라는 프롬프트가 떨어질 것이다. 이제 커널 이미지 디스크를 플로피 드라이브에 끼워 놓고, 다음의 내용을 입력하자.
promtp_ramdisk=1
MILO 는 부트 디스크에서 리눅스 커널을 읽어서 그것을 실행시킬 것이다. 커널이 부트한 다음에, 램디스크를 넣으라는 메시지가 나올 것인데, 이때, 미리 만들어둔 램디스크 플로피를 플로피 드라이브에 끼워 넣고 Enter를 누르자. 플로피를 모두 다 읽어들였으면 이제 어디서 본듯한 화면이 나타날 것이다. 여기서 부터는 인텔 리눅스 설치와 동일하므로 편안한 마음으로 커피를 한잔하면서 설치과정을 따라하면 될 것이다.
리눅스를 부팅하려면 MILO 이미지가 필요한데, 언제까지 플로피를 사용할 수만은 없으므로 파티션 설정시에 첫번째 파티션에 6메가(최소 2메가)정도로 FAT 분할을 잡아두도록 한다. 앞서도 이야기 했지만 AlphaBIOS 에서 FAT 과 ISO9660 파일 시스템만을 읽어들일 수 있기 때문이다. 리눅스에서 사용하는 FAT 파티션 이름은 "DOS 16-bit >=32"이다. 한가지 더 생각해야 할 점은 시간설정시에 ARC 콘솔에서 읽어오도록 설정하는 것이다. 이후에 이것은 /sbin/timeconfig 명령으로 다시 설정할 수 있다. 설치과정의 제일 마지막에는 앞서 사용한 커널 플로피를 넣어주어야 한다. 필자와 같이 무턱대고 엔터키만 치다가는 마무리 과정에서 실수를 하여 말짱 도루묵으로 만들 가능성이 있으므로 주의하는 것이 좋다. :) 혹시나 램 디스크 이미지를 넣어둔 채로 엔터키만 쳤다면 설치를 처음부터 다시 시작해야 한다(레드햇 4.2에의 경우). 네트웍에 물려있지 않는 컴퓨터일 경우에는 yp 시리즈 패키지와 amd를 설치 도중에 제외시켜주는 것이 좋다. 이들은 네트웍 패키지 부분에 있는데, 시스템을 설정하기 힘들 정도로 방해를 한다. 물론 네트웍을 물려 놓으면 정상적이다.
설치가 끝났다면 리눅스로 재부팅해보자. 앞서 이야기한 MILO 이미지를 저장할 분할 공간을 FAT 으로 파일 시스템을 만들지 않았다면 만들어 보자. 물론 이미 FAT파일 시스템을 만들었다면 안해도 된다. 여기서는 /dev/hda1을 예로 든다.
이제 마운트 하고, MILO플로피에 든 내용을 복사한다.
mcopy a:* /mnt/dos
linload.exe 와 milo 두개의 파일이 복사될
것이다.
이제 MILO 플로피 없이 부팅이 가능하다. AlphaBIOS 에서 이전에
설정한 Linux 부팅 메뉴의 내용을 바꾸어 보자. 여기에서는 리눅스 부팅
파티션이 /dev/hda3 이라고 가정한다.
Boot Name: Linux Boot File Disk 0, Partition 1 \ linload.exe OS Path : CD \ milo OS Option: boot hda3:vmlinux.gz root=/dev/hda3
이제 플로피에서 MILO를 읽어들이지 않고,
첫번째 FAT 파티션에서 읽어들인다.
OS Option 의 내용은 MILO 프롬프트에서
수동으로 타이핑하는 내용이다. hda3 대신에 자신의 파티션 상황에 맞게
바꾸어주면 된다. OS Path 내용은 부팅에 영향을 주지 않으므로, 저장시에
나타나는 경고메시지에는 신경쓰지 않아도 된다. OS Option를 지정해 주지
않는다면, MILO 프롬프트에서 수동으로 boot명령을 사용하여 일일이 지정해줘야
한다.
이것은 SCSI 하드디스크의 두번째 파티션의 예이다. vmlinux.gz 이라는 이름 말고도 다른 이름의 커널을 적재할 수도 있다. 시스템에 문제가 생겨서 single 모드로 들어가려면 마지막에 single을 적어 주면 된다.
알파에서 Linux 와 NT 의 멀티부팅이 가능하다. NT는 바이오스에서 제공하는 NT설치 메뉴를 누르기만 하면 모두 설치해준다. 하지만 NT가 제멋대로 잡는 경향이 있으므로 리눅스를 먼저 설치하기를 권한다. 그렇지 않으면 NT에서 확장 파티션까지 잡아버려서 이후에 리눅스 설치가 곤란해진다. NT 설치 도중에도 약간의 분할 공간이 필요하다. NT OS Loader 가 여기에 저장된다. 이것도 FAT 을 요구하기 때문에 멀티부팅을 하려면 , MILO 를 저장하기 위해 분할한 6GB 공간을 NT 부팅시에도 함께 사용할 수 있으므로 매우 효율적이다. 프라이머리 E-IDE타입의 대략 3.2GB 용량의 하드에 설치한다고 가정했을 때, 대략 다음과 같이 파티션을 잡을 수 있을 것이다.
파티션 용량 역할
hda1 6MB MILO자동부팅 영역 NT가동파일 저장 영역(NT에서 C:) hda2 120MB 리눅스 스왑 파티션 (메모리 128MB의 경우의 예) hda3 1500MB 리눅스 주 파티션 hda4 1500MB NT 주 파티션(NT 에서 D:)
여기에서 hda1은 리눅스 자동 부팅을 위한 milo 이미지와 milo로더인 linload.exe가 저장되는 공간이며, 동시에 NT에서 사용할 가동 파일과 몇몇 중요 파일을 저장하는 공간으로 사용할 수 있다. 파일 시스템이 FAT 이기 때문에 동시 사용이 가능한 것이다.
리눅스 커널은 하나에 모든 아키텍쳐에 필요한 소스들이 들어가 있다. 기본적으로 인텔 리눅스 사용자들이 월등히 많기 때문에 Makefile 에 arch -= i386 이라는 구문이 들어가 있다. 아키텍쳐에 의존적인 부분은 /usr/src/linux를 기준으로 했을 경우에, include 와 arch 디렉토리에 모여있다. 아마도 리눅스를 표준으로 설치하였다면 /usr/src/linux에 커널 소스가 들어가 있을 것이다. 없다면 때묻지 않은 (누군가에 의해 이후에 패치되지 않는) 커널 소스를 sunsite 같은 곳에서 구해서 표준 디렉토리(/usr/src)에서 풀어놓자. 필자는 커널 버젼 2.0.32를 권장한다. 아무래도 2.0.32이전 것은 fragment 버그가 아직 패치되지 않았기 때문이다.
PC164LX 와 PC164SX 같은 최근 기종의 알파 시스템을 사용하고 있다면, 반드시 커널 패치가 필요하다. 커널 패치는 다음에서 구할 수 있다.
patches-2.0.32-0.1.gz
gatekeeper 사이트의 같은 디렉토리에 보면 2.0.30에
대한 커널패치도 함께 있으니 참고하기 바란다.
커널 패치를 하는 방법은
다음과 같다.
tar xvzf linux-2.0.32 tar.gz
In -s linux old
gzip -dc alpha-patches-2.0.32-0.1.gz｜patch -p0
이제 준비과정은 끝났으므로 커널 컴파일에 들어가
보자.
알파에서의 커널 컴파일은 인텔과 비슷하나 make zImage 대신에 make
boot를 사용한다.
make menuconfig (menuconfig 대신에 xconfig. config 도 사용가능)
make dep
make clean
make boot
make modules
make modules_install
커널 설정시에 시스템 타입으로는 자신의 아키텍쳐에 맞는 항목으로 지정해야 한다. 그렇지 않으면 컴파일에 실패하거나 이후의 정상적인 사용에 지장을 줄 수 있다.
☞ 에러1 : 시간이 맞지 않다는 메시지
컴파일시에
Makefile과 소스파일의 시간이 맞지 않다는 메시지가 나온다면, 설치할 때 시간
설정이 잘못되어서 그런 것이다. 시간 설정이 올바른가 AlphaBIOS 에서 다시
점검하고 소스파일의 시간을 동일하게 설정한다.
☞ 에러2: PYXIS 에서 에러가 발생
pyxis는
21164A 에 바탕을 둔, 메모리 제어와 PCI 접근을 가능하게 해주는 핵심 논리
회로의 내부적인 이름이다. 21164A 기종을 사용하지 않는다면 pyxis를 빼버려도
상관 없는데, 기본적으로pyxis에 대한 의존성을 자동으로 설정해 버리는 경우가
많으므로 손으로 직접 수정해 준다. make menuconfig를 마친 다음 이후 컴파일
과정을 수행하기 전에 다음의 파일을 편집한다.
이 파일에서,
을 찾아서 다음으로 수정한다.
autoconf.h 파일은 커널 설정을 마친 이후에
특정 기능의 포함유무를 결정하기 위해 자동으로 생성되는 헤더 파일이다.
이제 남은 커널 컴파일 작업을 그대로 수행하면 된다.
성공적으로 컴파일을
마쳤다면, arch/alpha/boot/에 vmlinux.gz이라는 부팅 가능한 압축 커널이 생성된다.
인텔과는 달리 알파에서는 커널에 대한 추가적인 작업 없이 바로 / 디렉토리에
복사만 하면 부팅할 수 있다. / 디렉토리의 이전의 vmlinux.gz 을 vmlinux.old
로 백업해두고 새로 만들어진 vmlinux.gz 을 복사해 둔다.
☞ 에러3: 새롭게 만든 커널이 부팅이 안된다면
MILO 가 시작될 때 엔터키를 눌러서 MILO 프롬프트로 들어간다. 이전의 커널로
부팅을 하면된다. 가령 이전의 커널이 /vmlinux.old 이고, /dev/hda3 에 있다면
다음과 같이 부팅하면 된다.
커널 컴파일을 다시 시도한다.
☞ 에러4: 화면에 다음과 같은 트랩 에러와 관련된 지저분한 메시지가 나타난다면
unaligned trap at 0000000000000024: 000000004001d0e 28 1
unaligned trap at 0000000000000024: 000000004001d712 28 27
unaligned trap at 0000000000000024: 000000004001d0e 28 1
이런 경우에 대부분은 커널이 정확히 자신의
CPU 와 맞지 않기 때문에 발생한다. 같은 알파 시스템이라 하더라도 아키텍쳐에
따라 여러 종류가 있으므로, 커널 컴파일 시에 정확히 자신의 시스템을 선택하도록
한다. 해당하는 종류가 없다면 알파 커널 패치를 찾아보도록 하자.
EM86이란 무엇인가?
EM86 은 x86 리눅스
바이너리를 알파에서 실행할 수 있도록 해주는 애물레이터이다. 참고로 알파
NT 에는 x86 바이너리 변환툴로 FX!32라는 것을 사용한다. EM86을 사용하면 속도는
상당히 저하된다. 꼭 필요한 경우라면 EM86 을 사용해볼 수도 있겠다.
EM86을 사용하려면 두가지 작업을 해야 한다. 하나는 EM86을 적용시키기 위한 커널 패치이고 다른 하나는 필요한 소프트웨어의 설치이다. 알파 리눅스는 4GB의 위에 존재하는 가상 메모리를 프로세스에게 할당한다. 하지만 알파에서 실행되는 x86 프로그램이 수행되는 것을 감지하고, 자체 메모리 할당 계획에 따라 어드레스를 수행한다. EM86 커널 패치는 커널 2.0.30 용으로 나와 있으며, 다음에서 구할 수 있다.
여기에서 kernel-patches 디렉토리의 alpha-patches-2.0.30-0.2a.gz 을 가져온다. 먼저 EM86 적용을 위한 커널 패치를 해보자.
gzip -dc alpha-patches-2.0.30-0.2a.gz｜patch -p1
커널 패치 이외의 EM86 을 지원하는 소프트웨어와 라이브러리들은 RPMS 디렉토리에 rpm 으로 묶여 있다. 여기에 있는 소프트웨어를 모두 설치할 필요는 없다. 반드시 필요한 것은 다음의 3개이다.
rpm -ivh --ignorearch em86-x86-2.0-1.i386.rpm
rpm -ivh em86-baselibs-0.2-1.alpha.rpm
이후에 설명하는 소프트웨어는 선택적으로 설치할 수 있다.
레드햇 4.0 을 포함한 이전 버젼에서는 아키텍쳐 식별자로 alpha가 아닌 axp 를 사용하므로, 4.0 버젼에서 설치하려면 모두 --ignorearch 를 명시하여 설치하여야 한다. 제거할 경우에도 쉘에서 제공하는 for문을 사용하면 편리하다.
지금까지 수행한 커널 패치와 EM86 소프트웨어와 라이브러리를 설치하였다면 x86용 프로그램을 하나 가져와서 실행시켜 보자. 커널 패치가 적용되지 않았다면 프로그램 실행시 에 다음과 같은 에러가 발생할 것이다.
x86 리눅스용 넷스케이프를 테스트 해본 결과 아주 잘 돌아갔다. 속도가 느린 게 좀 흠이다. x86용 hwp는 테스트 해본 결과 돌아가지 않았다. x86에서 사용되는 시스템 호출 중 몇개가 아직 알파 커널에서 구현되지 않는 것으로 보인다. 이와 같은 특정한 이유가 아니면 대부분 잘 돌아갈 것이다.
최신버젼의 알파 시스템인 PC164LX 및 PC164SX 같은 경우에는 원본 리눅스 커널에는 포함되어 있지 않으므로 시스템 타입을 맞추기 위해서는 패치를 해야 함을 앞에서 이야기하였다. 마찬가지로 EM86 커널 패치는 커널 버젼 2.0.30에 적용되며 모든 아키텍쳐에 공통된다. 따라서 EM86 커널 패치가 지원하는 버젼에서 자신의 아키첵쳐를 지원하지 않는다면 둘 중 하나를 포기하는 수 밖에 없다. 이럴 경우에 하나의 방법은 EM86 커널과 자신의 시스템 타입에 맞춘 커널을 따로 준비하여 필요에 따라 적절한 커널로 부팅하는 방법이 있긴 하지만 여전히 불편하다. 둘 중 하나는 포기해야 한다면 EM86을 포기하는 것이 좋다. EM86 은 추가적인 기능이지만 아키첵쳐를 정확히 맞추는 것은 커널 최적화의 기본 방법이기 때문이다.
EM86은 현재 버젼 0.2 까지 나와 있다. 사실
리눅스에서 사용하는 대부분의 프로그램은 소스와 함께 배포되는 경우가
많아서 직접 컴파일하여 사용하면 되므로 EM86을 사용해야 할 경우는 비교적
적다. EM86도 이제 점차로 좋은 성능을 보여줄 것으로 기대된다.
알파 리눅스는 64비트라는 것을 앞에서 이야기했다. gcc 와 glibc도 64비트로 이미 포팅이 되었다. 따라서 인텔 리눅스에서 알파 리눅스로 포팅하는 작업이 쉽다고만은 할 수 없다. 필자가 보기에는 인텔 리눅스에서 알파 리눅스로 포팅하는 것은 타 UNIX OS 로 포팅하는 작업과 비슷한 작업이 필요한 것 같다. 같은 리눅스 기종이라는 공통점 때문에 쉬운 점도 있지만 아키텍쳐의 상이함에서 나오는 감당못할 일도 더러 발생한다. 프로그램 중에서 특히 아키텍쳐와 밀접한, 그래서 커널의 헤더 파일을 바로 포함하여 사용하는 프로그램의 경우에는 포팅에 상당히 주의를 기울여야 한다. 이제 몇가지 주의해야 할 점을 살펴보도록 하자.
C 프로그램밍을 조금이라도 해본 분이라면 int 자료형은 아키텍쳐에 따라 정의되는 것으로 알고 있다. 그래서 int 자료형의 크기는 도스는 16비트, 인텔 리눅스는 32비트, 알파 리눅스는? 뜻밖에 32비트이다. 사실 int, short int, long int 등의 자료형에 대한 특별한 규정은 없다. 다만 여러 가지의 상황을 고려하여 신중하게 채택되었을 뿐이다.
알파 리눅스가 64비트이긴 하지만 아직 전반적인 32비트 환경을 고려하여 int 를 32비트로 머물러 두게 한 것 같다. 대신에 long int는 64비트(8바이트)이다. 인텔 리눅스에서 long int 는 32비트(4바이트)이기 때문에 주의하는 것이 좋다. 더 재미있는 것은 포인터의 자료형 크기가 64비트라는 것이다. 즉, 메모리 주소를 가르킬 때는 보통 인텔 리눅스에서는 그대로 32비트를 사용하는 반면 64비트인 알파에서는 64비트의 크기를 사용한다. 따라서 흔히 범하기 쉬운 int 자료형과 포인터 자료형의 묵시적인 상호 형변환(cast)은 데이터의 변질을 가져오거나 코아덤프를 만날 수 있으므로 주의해야 한다. 이러한 아키텍쳐에 따라 달라질 수 있는 데이터형을 정확히 지정하기 위해 GNX libc 에서는 다음과 같은 자료형을 사용할 수 있도록 배려하고 있다.
int16_t : 16비트 크기의 부호있는 정수
int32_t : 32비트 크기의 부호있는 정수
int64_t : 64비트 크기의 부호있는 정수
u_int8_t : 8비트 크기의 부호없는 정수
u_int16_t : 16비트 크기의 부호없는 정수
u_int32_t : 32비트 크기의 부호없는 정수
u_int64_t : 64비트 크기의 부호없는 정수
리눅스 프로그램을 작성할 때 struct termio 와 struct termios를 그냥 섞어서 사용할 경우가 더러 있다. 이 둘의 인터페이스는 역사적인 이유 때문에 서로 호환이 되지 않는다. 따라서, struct termio를 사용하려면 TCGETA, TCSETAF, TCSETAW, TCSETA를 사용하여야 하고, struct termios를 사용하려면 TCGETS, TCSETSF, TCSETSW, TCSETS를 사용하여야 한다.
보통 머쉰의 최소 데이터 처리단위 (word)는
원자화된다. 즉, 이러한 데이터를 메모리에서 한번 읽거나 쓰는 작업은 단 한번의
CPU 명령으로 처리되기 때문에 그 사이에 다른 작업이 끼어들 수 없다. 특기,
이전에 출시된 알파 칩에서는 8비트(Byte)나 16비트(short)를 읽고 쓰는 명령은
단 하나의 명령으로 원자화되지 못했다. 이러한 구조는 장치나 인터럽트를 동기화시킬
때 문제점을 발생시킬 수 있다. 이와 관련하여 사용자 공간에서 고유 메모리를
통해 여러 프로세스가 데이터를 공유할 때에도 문제점이 발생할 수 있다.
요즘은 533MHz 정도의 알파 PC가 많이 알려져 있고 600MHz도 이미 개발이 끝나 있어서 곧 시판될 것으로 보인다. 알파 CPU의 개발은 현재 21164 에서 21264로 넘어가면서 1GHz 까지 나아갈 것 같다. Intel Pentium II 300MHz 와 Alpha 533MHz 정도를 비교하면 정수 연산에서는 1.5배, 부동 소숫점 연산에서는 3배 정도로 Alpha가 빠른 것으로 SpecFp95이 벤치마크 결과에 나와있다. 리눅스 상에서 CPU 성능의 빠르기로 측정되는 단위인 Bogmips 는 Pentium Pro 200이 200인데 비해 Alpha 533은 535 정도이다. 다음은 필자가 사용하고 있는 LX164의 CPU정보를 보기 위해 proc 파일 시스템을 참조한 것이다. EM86으로 컴파일 하느라 CPU 정보가 조금 달라져 있다.
필자가 몇달간 알파 시스템을 사용해 본 결과는 아주 만족스러웠다. 무엇보다도 속도면에서 시원스러움을 느끼게 해주었다. 커널 컴파일 시에도 담배 한대를 끝까지 태울 시간적인 이유를 주지 않는다. 하지만 알파 리눅스에도 문제는 있다. 가장 큰 문제점은 알파용 바이너리의 빈곤을 들 수 있다. 얼마전에 CD 라이터 프로그램을 gopher에서 찾을려고 했는 데, rpm 파일은 모두 i386 바이너리였다. 국내에서도 점차로 알파 사용자가 늘어나고 있는 추세이므로 사용하기 편리해질 것으로 기대한다. 두번째 문제는 커널 컴파일의 어려움이다. 커널 컴파일의 경우에는 의존성을 다시 설정하는 번거로운 작업을 거쳐야 할 경우가 한번씩 있다. 어떠한 추가 장치를 하나 인식시키려면 커널 컴파일을 보통 다시 하는데 이럴 경우에 인텔 리눅스에서 커널 컴파일에 익숙하다고 하더라도 조금 힘든 점이 없지 않아 있다. 이런 부분들도 점차로 알파 쪽 커널이 발전되어감에 따라 해결될 것으로 보인다.