물론 POSIX를 지원한다고 해서, 바이너리 수준의 호환성을 지원하는게 아니라
리눅스의 ELF 실행 파일들을 윈도우에서 실행할수도 있는게 아닌데
왜 MS Windows에서 POSIX를 지원하고 그걸 따르려는지는 조금 의문이었다.
(물론 미국정부 입찰시 정부 요구사항으로 POSIX 호환을 요구했다지만..)
개인적으로는 윈도우의 POSIX 를 따르는 것 중 하나가
NT 커널로 오면서 Program Files / Windows / Documents and Users 등의 File system hierachy 등부터
사용자 관리 등을 포함하는게 아닐까 싶었는데 음.. 이것과는 좀 다른것 같기도 하다.
모노리딕 커널은 현재 Linux 에서 채용하고 있는 커널의 구조이며,
모든 OS의 기능을 커널 영역(kernel space <-> user spcae)에서 관리자 모드(supervisor mode)로 구동한다.
A monolithic kernel is a kernel architecture where the entire operating system is working in the kernel space and alone as supervisor mode.
이에 반해, 마하 커널은
최소한의 기능만을 커널 영역에서 관리자 모드로 실행하며, 나머지 기능들을 유저 모드에서 실행을 한다.
다르게 말하면, 사용자별로 분리되어 작동하므로 커널을 침범하지 않아 보안의 문제가 줄어들며
개별유저가 시스템 전체를 망가트릴 정도로 문제가 확대되지 않는 구조적인 장점을 갖는다.
하지만, 이는 프로세스 간의 통신(IPC)에 부하가 많아지므로 전체성능이 오히려 떨어질 수 있는 우려가 있다.
The microkernel approach consists of defining a simple abstraction over the hardware, with a set of primitives or system calls to implement minimal OS services such as memory management, multitasking, and inter-process communication. Other services, including those normally provided by the kernel, such as networking, are implemented in user-space programs, referred to as servers. Microkernels are easier to maintain than monolithic kernels, but the large number of system calls and context switches might slow down the system because they typically generate more overhead than plain function calls.
간단하게 예를 들자면, 리눅스의 경우 Xwindow와 같은 그래픽 계열은
전부 User spcae에서 돌리는데 이로 인해 초기의 Xwindow는 MS Windows에 비하면 상당히 반응속도도 느렸는데
이는 리눅스는 monolithic kernel + user space Xwindow application 조합이었고
윈도우즈는 커널과 그래픽 부분이 결합되었기 때문에 통신에 대한 부하가 적었기 때문이다.
하지만, 이러한 구조적 차이로 리눅스는 가벼운 커널을 유지한 반면, MS Windows는 무거운 커널을 지니게 되었다.
머.. 현재의 시스템은 충분히 빨라졌고 알고리즘의 향상으로
Xwindow나 MS windows나 아주 큰 속도의 차이는 나지 않는것 같기 때문에 굳이 구분할 이유가 있나 싶기도 하다.
아무튼, 결국에는 하이브리드로 수렴하지 않을까 싶다.
Options:
-d confdir Specify an alternative configuration directory.
-k Keep temporary directory used to make the image.
-o outfile Write to outfile.
-r root Override ROOT setting in mkinitrd.conf.
See mkinitramfs(8) for further details.
아무튼 나의 경우에는, apt-get으로 받은 우분투 커널 소스를 컴파일 하여 설치된 경로가
/usr/src/linux-source-2.6.32 였고, 컴파일 하여 생성되는 모듈들의 경로는
/lib/modules/2.6.32.15+drm33.5/ 였다. 이런 이유로, uname 으로 출력되는 경로와 다르게 되어
기본값으로 생성되는 initrd.img의 내용에는 modules.dep 파일이 없어서 구동이 되지 않는다.
물론, initrd.img의 크기는 실제 장착된 메모리의 용량을 넘어서지만 않으면 된다고 하지만,
내가 생성해낸 이 파일의 용량은 65M가 되어서 부팅에 조금 오래 걸리고,
약간의 설정상 문제가 있는지 Xwindow가 구동하지 않았다 -_-
귀찮아서 initrd 를 2.6.32.24 걸로 끌어다 썻더니 부팅은 시도하지만
커널과 관련된 파일들이 없어서 부팅이 진행되지는 않는다.
그래서 검색을 해보니, make modules_install 을 해주거나 depmod 를 해주면 되는 것으로 추측된다.
cd linux-2.6.30/drivers/gpu/drm/i915/
patch i915_drv.c /tmp/patch # make any modification you need here
make -C /usr/src/linux-headers-`uname -r` M=`pwd` modules
sudo make -C /usr/src/linux-headers-`uname -r` M=`pwd` modules_install
sudo depmod -a
Options:
-d confdir Specify an alternative configuration directory.
-k Keep temporary directory used to make the image.
-o outfile Write to outfile.
-r root Override ROOT setting in mkinitrd.conf.
See mkinitramfs(8) for further details.
FILES
/etc/initramfs-tools/initramfs.conf
The default configuration file for the script. See initramfs.conf(5)
for a description of the available configuration parameter.
/etc/initramfs-tools/modules
Specified modules will be put in the generated image and loaded when
the system boots. The format - one per line - is identical to that of
/etc/modules, which is described in modules(5).
/etc/initramfs-tools/conf.d
The conf.d directory allows to hardcode bootargs at initramfs build
time via config snippets. This allows to set ROOT or RESUME. This is
especially useful for bootloaders, which do not pass an root bootarg.
/etc/initramfs-tools/DSDT.aml
If this file exists, it will be appended to the initramfs in a way that causes it to be loaded by ACPI.
머 생성해도 달라지는건 별로 없군 ㄱ- busybox 에서 못 넘어 간다 (안해!!!! ㅆㅂ)
다른것들 보다는.. 도대체 왜
FATAL: Could not load /lib/modules/... : No such file or directory
라는 에러가 발생을 하는지 모르겠다.
---
/dev/sda1 대신 /dev/hda1을 바꾸면 될까 했는데.. 역시나 안되고 -_-
(sda1은 SATA 하드 hda1은 IDE용 하드의 식별자이다)
혹시나 해서 initrd의 내용을 열어보니
conf/conf.d/resume 파일의 내용중 UUID의 값이 /boot/grub/grub.cfg 의 내용과 다르게 들어있었다.
그리고 이 내용은
/etc/initramfs-tools/conf.d/resume에 들어있던 내용이고
mkinitramfs 에 의해 이 내용이 들어간 것으로 보인다.
Extracting initrd image
Initrd image is just cpio-gzip archive. So to extract it:
집에와서 해보니, BIOS 에서 부터 Shift를 누르는것은 들어가지지 않고,
BIOS 에서 Bootloader로 넘어가는 시점에서 부터 Shift 키를 누르고 있어야 GRUB loader menu로 진입하였다.
눌렀다 뗐다 하는것도 안되고, 계속 메뉴가 뜰때까지 누르고 있어야 하는데 음.. 이건 촘 아니라는 느낌..