kernel compile과 kernel 분석은 연관성이 그리 많지는 않습니다. 그리고 x-windows는 kernel에 포함되어 있지 않습니다. x-windows는 xlib(Application Level) 기반하에 xfree86 혹은 xorg가 존재하는 것이지요. kernel에는 단지 그래픽 드라이버가 존재하는 것이지요.
kernel을 분석하려면, kernel의 어떠한 부분을 분석할 것인지와, 아키텍쳐 선정 등을 우선시 하셔야 합니다. 부팅과정을 분석하신다면, 해당 아키텍쳐의 부트 루틴부터 쫓아가시면서 분석하시면 되고, device driver를 분석하시려면, 분석하시려는 device driver 소스를 보시면 됩니다. 즉, 단순히 kernel을 분석하려고만 생각하시면, kernel의 양으로 인해서 힘드실수밖에 없기 때문에, kernel의 어느부분을 분석하겠다는 것을 정확히 고려하시고 시작하시는게 좋습니다.
그리고, 배포본에 대해서 첨언하자면, 일단, kernel 분석에 있어서 젠투든, 우분투든, 어차피 바닐라 kernel 가지고 분석하는 것이 좋기 때문에, 배포본에 영향을 받지 않습니다. 또한 젠투만이 매뉴얼로 셋팅할 수 있는 것은 아닙니다. 우분투 외 그 어떤 배포본도, kernel.org로부터 바닐라 커널을 받아서 자체적으로 coustomizing할 수 있습니다. 자꾸 이러한 부분에서 젠투 얘기가 나오는데, 그 어떤 배포본도 할 수 있는 일을 꼭 젠투만이 좋은 것처럼 많이 느껴져서, 좀 아쉽네요.
------------------------------------------------------
아직은 젊다. 모든 것을 할 수 있는 나이란 말이지.
------------------------------------------------------
아직은 젊다. 모든 것을 할 수 있는 나이란 말이지.
1. GUI (X window 같은 거) 없이 커널을 분석하고 싶은데 배포판 같은 것에는 기본으로 X window가 있어서 kernel configuration 을 최소화 할 시 X window에 영향 때문에 안되는 경우가 많다는 거지요.특히 kernel compile시 너무 시간이 많이 걸리니 kernel에 포함된 것을 최소화 하고 싶다는 게 제 생각입니다. 그렇기 위해서는 GUI 같은 부분은 포함이 안되게 하면 좋은 데 방법을 잘 모르겠군요 (혹, 배포판 없이도 커널 로딩할 수 있는가요?)
입니다.
p.s
커널 분석하실 때 일반 배포판 에서 수행하셨나요? 저는 Virtual Box 사용해서 Ubuntu 9.04로 하고 있는데 한번 컴파일 하는데 너무 시간이 많이 걸리고 안좋네요
팁좀 알려주세용..
뷜드속도는 distcc나 icecream (http://en.opensuse.org/Icecream) 사용하시면 빠르게 할 수 있는데 icecream 추천합니다. 컴파일 환경을 호스트에서 가지고 가기때문에 컴파일러 버젼같은 거 안 맞춰도 되고 cross-compile할 때도 사용할 수 있습니다. 뷜드시 디스크에 오브젝트 기록하는 속도가 바틀넥이 될 수도 있는데 그런 경우엔 tmpfs를 뷜드 아웃풋 디렉토리로 사용하고 swap 넉넉히 잡고 사용하면 됩니다.
컨픽옵션은 make defconfig 한 후에 menuconfig해서 필요한 하드웨어 지원부분이나 필요한 디버깅 옵션 켜고 사용하면 되고, 테스팅은 qemu-kvm 사용하면 편합니다. 커널 뷜드하고 바로 qemu-kvm -kernel BUILD_DIR/arch/x86/boot/bzImage -curses로 실행하면 터미널에서 바로 뷜드된 커널로 부팅합니다. kvm 지원이 없으면 그냥 qemu 사용해도 되지만 좀 느린편 이구요. 참고로 제 뷜드 / 테스트 스크립트들은 다음과 같고,
> cat ~/bin/lmake
#!/bin/bash
time nice make -j36 O=build "$@"
> cat ~/bin/qemu-test
#!/bin/bash
ccache가 quilt 같은 거 사용해서 push/pop 하면서 반복적으로 했던 거 또 할 땐 괜찮은데, 소스 실제로 고치면서는 오히려 느려지기만 하더라구요. make가 어차피 실제로 영향을 받는 화일들만 새로 뷜드하는데 바뀐 결과물과 동일한 결과물을 뷜드한 적이 없으면 (소스 고치면서 뷜드하면 대게 다 이렇죠) distcc는 그냥 오버헤드만 더하는데다가 오브젝트 화일들을 따로 잔뜩 기록해서 안그래도 느린 디스크가 더 버벅거리게 되서 같은 내용을 여러번 뷜드할 걸 미리 아는 특별한 상황이 아니면 별 쓸모 없는 거 같습니다.
막상 해보니깐 매번 할때마다 엄청난 시간이 걸리더라구요.. (제가 하는 방식이 맞는지 모르지만요)
제가 사용한 방법은 다음과 같습니다.
1. 일단 전체적으로 커널 컴파일 다 하구요 (make bzImage;make modules; make modules_install; make install )
2. 필요한 부분 수정
3. 다시 make bzImage; make install (모듈은 따로 건드리지 않았다고 한다면)
그냥 make 하면 bzImage와 modules까지 하고, 수정하는 화일이 어디냐에 따라서 다른데 전체적으로 include되는 해더화일을 편집하면 거의 전체를 다 뷜드하니까 실제로 뷜드 속도를 빠르게 하는 거 말곤 해결책이 없습니다. .c 화일들이나 서브시스템 해더화일들 같은 건 가볍게 할 수 있구요. 돈을 아주 아껴야 하는 상황이 아니면 쿼코 기계 두대만 있어도 .config이 적당한 크기면 별 부담없이 뷜드할 수 있습니다. 제 경운 데탑을 포함해서 쿼코 세대로 뷜드하는데 주로 사용하는 작지도 크지도 않은 .config으로 전체 뷜드하는데 80초 약간 넘게 걸립니다. 몇가지 확인해볼 것들은요.
* 화일 타임스템프가 엉뚱하게 찍히면 (주로 소스가 nfs로 마운트 되어있고 편집하는 호스트의 시간과 뷜드 호스트의 시간이 다를 때) make가 어느 화일이 바뀌었고 아닌 지 구분을 못해서 다 뷜드할 수 있습니다.
* 최종 링크 과정을 제외하곤 뷜드에 참가하는 모든 호스트들의 모든 cpu 사용량이 100에 가깝게 유지되야 합니다. 멀티코어 호스트에서 뷜드하면 한대에서도 오브젝트 기록 속도가 생성 속도를 못 쫒아가는 상황이 자주 생깁니다. tmpfs 사용하면 해결할 수 있습니다.
* 조금 편집하고 얘가 뷜드나 되는지 확인해볼 땐 타겟 c 파일들만 우선 뷜드해보면 됩니다.
커널 컴파일 시간이 방해요소가 될 일은 실상 그다지 많지 않다고 봅니다.
직접 소스를 수정하시면서 빌드한다고 해도, 변경된 부분만 다시 빌드가 되니까요.
단, 핵심 헤더 파일을 고치신다면 거의 다 빌드가 되긴 하겠네요.
X-Window야 사실 있으나 없으나 별 차이가 없다고 말씀드릴 수 있습니다.
X-Window해봐야 그래픽 드라이버, 사운드 드라이버 정도 관련되어 있을텐데, 그거 빌드한다고
크게 지장받을 일 전혀 없습니다.
사실상, 배포판 커널을 설치하면 엄청나게 많은 수의 드라이버가 config에 포함되어 있습니다.
커널 config을 최소화하고 싶으시다면 streamline_config.pl 이라는 스크립트를 사용해보세요.
- http://rostedt.homelinux.com/code/streamline_config.pl
사용하시는 hot-plug device (USB)가 있다면 연결된 상태에서 수행하셔야 합니다.
처음 fedora를 설치하면 1000개가 넘는 커널 모듈이 포함되어 있지만, 저같은 경우는 커널 모듈이 50여개 이하이네요.
컴파일 시간을 줄이는 ccache도 따로 사용하고 있습니다.
젠투를 ...
젠투를 한번 설치해 보세요.
커널도 메뉴얼로 셋팅하여서...
kernel compile과 kernel
kernel compile과 kernel 분석은 연관성이 그리 많지는 않습니다. 그리고 x-windows는 kernel에 포함되어 있지 않습니다. x-windows는 xlib(Application Level) 기반하에 xfree86 혹은 xorg가 존재하는 것이지요. kernel에는 단지 그래픽 드라이버가 존재하는 것이지요.
kernel을 분석하려면, kernel의 어떠한 부분을 분석할 것인지와, 아키텍쳐 선정 등을 우선시 하셔야 합니다. 부팅과정을 분석하신다면, 해당 아키텍쳐의 부트 루틴부터 쫓아가시면서 분석하시면 되고, device driver를 분석하시려면, 분석하시려는 device driver 소스를 보시면 됩니다. 즉, 단순히 kernel을 분석하려고만 생각하시면, kernel의 양으로 인해서 힘드실수밖에 없기 때문에, kernel의 어느부분을 분석하겠다는 것을 정확히 고려하시고 시작하시는게 좋습니다.
그리고, 배포본에 대해서 첨언하자면, 일단, kernel 분석에 있어서 젠투든, 우분투든, 어차피 바닐라 kernel 가지고 분석하는 것이 좋기 때문에, 배포본에 영향을 받지 않습니다. 또한 젠투만이 매뉴얼로 셋팅할 수 있는 것은 아닙니다. 우분투 외 그 어떤 배포본도, kernel.org로부터 바닐라 커널을 받아서 자체적으로 coustomizing할 수 있습니다. 자꾸 이러한 부분에서 젠투 얘기가 나오는데, 그 어떤 배포본도 할 수 있는 일을 꼭 젠투만이 좋은 것처럼 많이 느껴져서, 좀 아쉽네요.
------------------------------------------------------
아직은 젊다. 모든 것을 할 수 있는 나이란 말이지.
------------------------------------------------------
아직은 젊다. 모든 것을 할 수 있는 나이란 말이지.
kernel 분석 시
네 답변 감사합니다.
지금도 커널 분석을 위해 기본 단계를 하고 있는데 여전히 아쉬운 점은.
1. GUI (X window 같은 거) 없이 커널을 분석하고 싶은데 배포판 같은 것에는 기본으로 X window가 있어서 kernel configuration 을 최소화 할 시 X window에 영향 때문에 안되는 경우가 많다는 거지요.특히 kernel compile시 너무 시간이 많이 걸리니 kernel에 포함된 것을 최소화 하고 싶다는 게 제 생각입니다. 그렇기 위해서는 GUI 같은 부분은 포함이 안되게 하면 좋은 데 방법을 잘 모르겠군요 (혹, 배포판 없이도 커널 로딩할 수 있는가요?)
입니다.
p.s
커널 분석하실 때 일반 배포판 에서 수행하셨나요? 저는 Virtual Box 사용해서 Ubuntu 9.04로 하고 있는데 한번 컴파일 하는데 너무 시간이 많이 걸리고 안좋네요
팁좀 알려주세용..
---------------------------------
http://blog.naver.com/munhoney
---------------------------------
뷜드속도는 distcc나
뷜드속도는 distcc나 icecream (http://en.opensuse.org/Icecream) 사용하시면 빠르게 할 수 있는데 icecream 추천합니다. 컴파일 환경을 호스트에서 가지고 가기때문에 컴파일러 버젼같은 거 안 맞춰도 되고 cross-compile할 때도 사용할 수 있습니다. 뷜드시 디스크에 오브젝트 기록하는 속도가 바틀넥이 될 수도 있는데 그런 경우엔 tmpfs를 뷜드 아웃풋 디렉토리로 사용하고 swap 넉넉히 잡고 사용하면 됩니다.
컨픽옵션은 make defconfig 한 후에 menuconfig해서 필요한 하드웨어 지원부분이나 필요한 디버깅 옵션 켜고 사용하면 되고, 테스팅은 qemu-kvm 사용하면 편합니다. 커널 뷜드하고 바로 qemu-kvm -kernel BUILD_DIR/arch/x86/boot/bzImage -curses로 실행하면 터미널에서 바로 뷜드된 커널로 부팅합니다. kvm 지원이 없으면 그냥 qemu 사용해도 되지만 좀 느린편 이구요. 참고로 제 뷜드 / 테스트 스크립트들은 다음과 같고,
> cat ~/bin/lmake
#!/bin/bash
time nice make -j36 O=build "$@"
> cat ~/bin/qemu-test
#!/bin/bash
exec qemu-kvm -drive file=/devel/tj/qemu/test/test.img,if=ide,index=0,media=disk -drive file=/devel/tj/qemu/test/test1.img,if=ide,index=1,media=disk -m 512 -net nic,vlan=0,model=pcnet -net user,vlan=0 -cdrom /devel/tj/os/archive/openSUSE-11.1-DVD-x86_64.iso -redir tcp:6970::22 -serial file:/devel/tj/tmp/test.log -curses "$@"
뷜드 후 다음처럼 테스트합니다.
> qemu-test -kernel build/arch/x86/boot/bzImage -append "root=/dev/sda2 console=ttyS0 console=tty0 earlyprintk=ttyS0 loglevel=8 percpu_alloc=lpage numa=fake=4" -smp 8
실제 기계로 테스팅을 쉽게 하려면 netboot 설정해서 뷜드후 바로 부팅시키면 새 커널로 부팅하게 하면됩니다.
컴파일 시간
처음 분석하는데 컴파일 시간을 줄이는 게 목적이라면 괜히 "불필요한 부분"을 없애려 노력하지 마시고 ccache나 distcc같은 컴파일 시간을 줄여주는 컴파일러 캐시를 쓰시기 바랍니다.
ccache가 quilt 같은 거
ccache가 quilt 같은 거 사용해서 push/pop 하면서 반복적으로 했던 거 또 할 땐 괜찮은데, 소스 실제로 고치면서는 오히려 느려지기만 하더라구요. make가 어차피 실제로 영향을 받는 화일들만 새로 뷜드하는데 바뀐 결과물과 동일한 결과물을 뷜드한 적이 없으면 (소스 고치면서 뷜드하면 대게 다 이렇죠) distcc는 그냥 오버헤드만 더하는데다가 오브젝트 화일들을 따로 잔뜩 기록해서 안그래도 느린 디스크가 더 버벅거리게 되서 같은 내용을 여러번 뷜드할 걸 미리 아는 특별한 상황이 아니면 별 쓸모 없는 거 같습니다.
답변 감사합니다.
네 저 생각도 만약 한번 make 할때만 시간 걸리면 되겠지라고 생각했는데,
막상 해보니깐 매번 할때마다 엄청난 시간이 걸리더라구요.. (제가 하는 방식이 맞는지 모르지만요)
제가 사용한 방법은 다음과 같습니다.
1. 일단 전체적으로 커널 컴파일 다 하구요 (make bzImage;make modules; make modules_install; make install )
2. 필요한 부분 수정
3. 다시 make bzImage; make install (모듈은 따로 건드리지 않았다고 한다면)
그런데 make bzImage할 때 시간이 처음에 할 때랑 똑같더라구요..
이렇게 하는게 맞나요?
---------------------------------
http://blog.naver.com/munhoney
---------------------------------
그냥 make 하면
그냥 make 하면 bzImage와 modules까지 하고, 수정하는 화일이 어디냐에 따라서 다른데 전체적으로 include되는 해더화일을 편집하면 거의 전체를 다 뷜드하니까 실제로 뷜드 속도를 빠르게 하는 거 말곤 해결책이 없습니다. .c 화일들이나 서브시스템 해더화일들 같은 건 가볍게 할 수 있구요. 돈을 아주 아껴야 하는 상황이 아니면 쿼코 기계 두대만 있어도 .config이 적당한 크기면 별 부담없이 뷜드할 수 있습니다. 제 경운 데탑을 포함해서 쿼코 세대로 뷜드하는데 주로 사용하는 작지도 크지도 않은 .config으로 전체 뷜드하는데 80초 약간 넘게 걸립니다. 몇가지 확인해볼 것들은요.
* 화일 타임스템프가 엉뚱하게 찍히면 (주로 소스가 nfs로 마운트 되어있고 편집하는 호스트의 시간과 뷜드 호스트의 시간이 다를 때) make가 어느 화일이 바뀌었고 아닌 지 구분을 못해서 다 뷜드할 수 있습니다.
* 최종 링크 과정을 제외하곤 뷜드에 참가하는 모든 호스트들의 모든 cpu 사용량이 100에 가깝게 유지되야 합니다. 멀티코어 호스트에서 뷜드하면 한대에서도 오브젝트 기록 속도가 생성 속도를 못 쫒아가는 상황이 자주 생깁니다. tmpfs 사용하면 해결할 수 있습니다.
* 조금 편집하고 얘가 뷜드나 되는지 확인해볼 땐 타겟 c 파일들만 우선 뷜드해보면 됩니다.
우분투시라면 그냥
Ubuntu Server 버전을 설치하세요
설치하는데도 몇십분 안걸리고 용량도 별로 안되서 금방 환경이 갖춰지실겁니다.
대신 개발 패키지는 직접 설치해주셔야죠(이건 뭐 Ubuntu Desktop과 동일하니)
=================================
이제는 앞만 보며 전진해야만 할뿐.......
BLOG : http://khmirage.tistory.com/
==================================================================
정체된 일상.... 계기를 만들어야 하는데........
BLOG : http://khmirage.tistory.com/
커널 컴파일 시간이
커널 컴파일 시간이 방해요소가 될 일은 실상 그다지 많지 않다고 봅니다.
직접 소스를 수정하시면서 빌드한다고 해도, 변경된 부분만 다시 빌드가 되니까요.
단, 핵심 헤더 파일을 고치신다면 거의 다 빌드가 되긴 하겠네요.
X-Window야 사실 있으나 없으나 별 차이가 없다고 말씀드릴 수 있습니다.
X-Window해봐야 그래픽 드라이버, 사운드 드라이버 정도 관련되어 있을텐데, 그거 빌드한다고
크게 지장받을 일 전혀 없습니다.
사실상, 배포판 커널을 설치하면 엄청나게 많은 수의 드라이버가 config에 포함되어 있습니다.
커널 config을 최소화하고 싶으시다면 streamline_config.pl 이라는 스크립트를 사용해보세요.
- http://rostedt.homelinux.com/code/streamline_config.pl
사용하시는 hot-plug device (USB)가 있다면 연결된 상태에서 수행하셔야 합니다.
처음 fedora를 설치하면 1000개가 넘는 커널 모듈이 포함되어 있지만, 저같은 경우는 커널 모듈이 50여개 이하이네요.
컴파일 시간을 줄이는 ccache도 따로 사용하고 있습니다.
댓글 달기