[Linux] Kernel 이미지(zImage) 구조

gzip 으로 압축된 ramdisk 를 포함하는 zImage 는 다음과 같은 구조를 가진다.
zImage
– decompression code
– piggy.gz + piggy trailer
 + piggy.gz
  + piggy
   + kernel image
   + initramfs.cpio.gz + part3
    + initramfs.cpio.gz
     + initramfs.cpio
      + initramfs/
    + padding3
    + part3
  + padding piggy
  + piggy trailer

[Android] boot.img 구성

Android 에서 사용되는 boot.img 는 다음과 같이 구성되어 있다(ICS 기준).
각 구성부는 Page 크기에 맞춰 Align 되어 있다.
– Boot Image Header(1 page) (system/core/mkbootimng/bootimg.h 참고)
 + magic(8 bytes) : ANDROID!
 + kernel size(4 bytes)
 + kernel address(4 bytes)
 + ramdisk size(4 bytes)
 + ramdisk address(4 bytes)
 + second stage size(4 bytes)
 + second stage address(4 bytes)
 + kernel tags physical address(4 bytes)
 + page size(4 bytes)
 + reserved(8 bytes) : Should be 0
 + product name(16 bytes)
 + cmdline(512 bytes)
 + id(32 bytes) : timestamp, checksum, sha1, etc
– Kernel(zImage)
– Ram Disk
– Second stage

[Android] ext4 file system을 위한 빌드 설정 파일

오픈 소스의 Android Build 시스템을 확인해보면 Makefile 에 다음과 같이 system.img 나 userdata.img 등을 만들기 위한 옵션에 따른 처리가 있다.

build/core/Makefile

# #################################################################
# Targets for user images
# #################################################################
INTERNAL_USERIMAGES_EXT_VARIANT :=
ifeq ($(TARGET_USERIMAGES_USE_EXT2),true)
INTERNAL_USERIMAGES_USE_EXT := true
INTERNAL_USERIMAGES_EXT_VARIANT := ext2
else
ifeq ($(TARGET_USERIMAGES_USE_EXT3),true)
INTERNAL_USERIMAGES_USE_EXT := true
INTERNAL_USERIMAGES_EXT_VARIANT := ext3
else
ifeq ($(TARGET_USERIMAGES_USE_EXT4),true)
INTERNAL_USERIMAGES_USE_EXT := true
INTERNAL_USERIMAGES_EXT_VARIANT := ext4
endif
endif
endif

ifneq (true,$(TARGET_USERIMAGES_SPARSE_EXT_DISABLED))

  INTERNAL_USERIMAGES_SPARSE_EXT_FLAG := -s
endif

# $(1): src directory
# $(2): output file
# $(3): mount point
# $(4): ext variant (ext2, ext3, ext4)
# $(5): size of the partition
define build-userimage-ext-target
  @mkdir -p $(dir $(2))
  $(hide) PATH=$(foreach p,$(INTERNAL_USERIMAGES_BINARY_PATHS),$(p):)$$PATH \
          $(MKEXTUSERIMG) $(INTERNAL_USERIMAGES_SPARSE_EXT_FLAG) $(1) $(2) $(4) $(3) $(5)
endef
 
ifeq ($(INTERNAL_USERIMAGES_USE_EXT),true)
## generate an ext image
# $(1): output file
define build-systemimage-target
    @echo “Target system fs image: $(1)”
    $(call build-userimage-ext-target,$(TARGET_OUT),$(1),system,$(INTERNAL_USERIMAGES_EXT_VARIANT),$(BOARD_SYSTEMIMAGE_PARTITION_SIZE))

endef

$(BUILT_SYSTEMIMAGE): $(FULL_SYSTEMIMAGE_DEPS) $(INSTALLED_FILES_FILE)

        $(call build-systemimage-target,$@)
 

그래서 다음과 같이 ext4 사용, 파티션 사이즈, 그리고 sparse 이미지 여부를 설정해주면 그에 맞는 sytstem.img, userdata.img를 얻을 수 있다.
 

BoardConfig.mk

TARGET_USERIMAGES_USE_EXT4 := true
TARGET_USERIMAGES_SPARSE_EXT_DISABLED := true

BOARD_SYSTEMIMAGE_PARTITION_SIZE := 290979840
BOARD_USERDATAIMAGE_PARTITION_SIZE := 134217728
BOARD_FLASH_BLOCK_SIZE := 4096


ext4 sparse 이미지에 대해서는 system/extras/ext4_utils 의 make_ext4fs 툴의 소스 및 헤더파일을 살펴보면 알 수 있다.
 

[git] 어떤 commit 이 어느 브랜치에 있는지 확인하고 싶을 때

tag로 checkout을 한다던가 하게되면 이게 지금 어느 브랜치에서 나온건지를 알 수 없을 때가 있다. 또는 어느 commit 이 어느 브랜치 상에 있는지를 알고 싶을 때 라던가.. 이럴 때 사용할 수 있는 것이
git-what-branch 스크립트다.

https://github.com/SethRobertson/git-what-branch  

$ git-what-branch –allref <commit sha1 id>

 

[Linux] ioctl을 대체하는 unlocked_ioctl

기존 device driver를 제어하기 위한 방법 중 하나였던 ioctl이 2.6.36 커널부터 unlocked_ioctl 로 대체되었다.
ioctl과 unlocked_ioctl의 차이점은 ioctl이 BKL(Big Kernel Lock)로 보호되었다면, unlocked_ioctl은 BKL이 없다. 따라서 Preemptible 하게 되었으므로, ioctl의 동시성에 대해서 driver 스스로 보호하여야 한다.
driver의 제어를 위해서 ioctl보다는 sysfs를 이용하는 방향으로 가고 있는 듯 하다(http://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-May/001852.html).

compat_ioctl은 64비트 시스템에서 32비트 프로세스가 ioctl을 부를 때를 위해서 만들어졌다.

참고 : http://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-May/001851.html

gerrit 프로젝트 Mirroring 하기

gerrit을 사용하면 자기가 access 권한이 있는 프로젝트의 리스트를 ssh를 이용하여 ls-projects 라는 명령을 이용해서 얻어올 수 있다. http://gerrit-documentation.googlecode.com/svn/Documentation/2.2.0/cmd-ls-projects.html 를 참고하면 되는데, 해당 도움말을 보면 이 명령을 이용해서 접근 가능한 모든 Project 를 clone 할 수 있는 쉘 스크립트가 있다.

for p in `ssh -p 29418 review.example.com gerrit ls-projects`
do
  mkdir -p `dirname "$p"`
  git clone --bare "ssh://review.example.com:29418/$p.git" "$p.git" 

done 

이것과 crontab, shell script를 조금 응용하면 계속적으로 업데이트 함으로써 Mirroring 을 할 수 있다.

#!/bin/sh
PLATFORM_HOME=`readlink -e .`
PROJECT_LIST=`ssh -p 29418 review.example.com gerrit ls-projects`
ROOT=”ssh://review.example.com”
DIRNAME=”/usr/bin/dirname”
BASENAME=”/usr/bin/basename”
for PROJECT in $PROJECT_LIST
do
        cd $PLATFORM_HOME;
        echo “——————————————————–“
        echo ” $PROJECT.git”
        if [ -d $PROJECT.git ]; then
                echo “Entering $PROJECT.git”;
                cd $PROJECT.git;
                git remote update
        else
                echo “Cloning $ROOT/$PROJECT.git”;
                PROJECT_DIR=`$DIRNAME $PROJECT`
                mkdir -p $PROJECT_DIR
                git clone –mirror “$ROOT/$PROJECT.git” “$PROJECT.git”
        fi
done

 미러링 사용시에는 받아오기 전에 다음 명령과 같이 설정하여 사용하면 된다.

 git config –global url.”git://<IP>”.insteadOf “git://codeaurora.org”

Linux kernel, ramdisk 사용 및 Android 빌드 시스템에서의 설정

Linux 커널의 경우 램디스크를 여러 종류를 사용하는데 이 중 initramfs/initrd 를 사용하는 경우
CONFIG_BLK_DEV_INITRD 를 설정하고, CONFIG_INITRAMFS_SOURCE 에 root 파일템이 만들어져 있는 디렉토리 경로를 써준다.
Android 빌드 시스템에서는 커널 및 램디스크를 합쳐서 boot.img 를 만들어 사용하는데,
이 때, 사용될 Kernel Command line 을 지정할 수 있다. 이 때 TARGET_NO_KERNEL은 false 여야 한다.
이는 build/core/Makefile 에서 확인할 수 있다. 

BOARD_KERNEL_CMDLINE := $(strip $(BOARD_KERNEL_CMDLINE))
ifdef BOARD_KERNEL_CMDLINE
  INTERNAL_BOOTIMAGE_ARGS += –cmdline “$(BOARD_KERNEL_CMDLINE)”
endif

이 외에도 Kernel Base address, Page Size 등도 지정할 수 있다.

BOARD_KERNEL_BASE := $(strip $(BOARD_KERNEL_BASE))
ifdef BOARD_KERNEL_BASE
  INTERNAL_BOOTIMAGE_ARGS += –base $(BOARD_KERNEL_BASE)
endif
BOARD_KERNEL_PAGESIZE := $(strip $(BOARD_KERNEL_PAGESIZE))
ifdef BOARD_KERNEL_PAGESIZE
  INTERNAL_BOOTIMAGE_ARGS += –pagesize $(BOARD_KERNEL_PAGESIZE)
endif

TARGET_BOOTIMAGE_USE_EXT2 를 true로 하면 ext2 파일시스템의 boot image를 만드는 것 같다.

ifeq ($(TARGET_BOOTIMAGE_USE_EXT2),true)
tmp_dir_for_image := $(call intermediates-dir-for,EXECUTABLES,boot_img)/bootimg
INTERNAL_BOOTIMAGE_ARGS += –tmpdir $(tmp_dir_for_image)
INTERNAL_BOOTIMAGE_ARGS += –genext2fs $(MKEXT2IMG)
$(INSTALLED_BOOTIMAGE_TARGET): $(MKEXT2IMG) $(INTERNAL_BOOTIMAGE_FILES)
    $(call pretty,”Target boot image: $@”)
    $(hide) $(MKEXT2BOOTIMG) $(INTERNAL_BOOTIMAGE_ARGS) –output $@
else # TARGET_BOOTIMAGE_USE_EXT2 != true
$(INSTALLED_BOOTIMAGE_TARGET): $(MKBOOTIMG) $(INTERNAL_BOOTIMAGE_FILES)
    $(call pretty,”Target boot image: $@”)
    $(hide) $(MKBOOTIMG) $(INTERNAL_BOOTIMAGE_ARGS) –output $@
    $(hide) $(call assert-max-image-size,$@,$(BOARD_BOOTIMAGE_PARTITION_SIZE),raw)
endif # TARGET_BOOTIMAGE_USE_EXT2

예제)

TARGET_NO_KERNEL := false
BOARD_KERNEL_BASE := 0x30000000
BOARD_KERNEL_PAGESIZE := 4096
BOARD_KERNEL_CMDLINE := console=ttyFIQ0 no_console_suspend

git/gerrit 사용시 알아야 할 것

git과 gerrit 을 사용할 때 최소한 알아야 하는 것을 정리한 것으로 회사 내의 git 교육 담당자에게 교육 시 필요한 내용을 정리해서 보낸 내용이다. 이거 다 알면 git 잘 쓴다^^
이것을 차례로 삼아 세부 내용을 하나씩 문서로 만들어 정리하자.

추가1: 이미 http://namhyung.springnote.com/pages/3132772 에 git 사용자 설명서가 있다. 저 namhyung님이 내가 아는 우분투 쪽 김남형 님일까 ㅎㅎ

추가2: http://git-scm.com/book/ko 번역자에게 축복을…

* git
1. Git의 Repository 개념과 clone 의 개념, clone

2. Git의 remote branch와 local branch 간 차이, fetch
3. Remote 브랜치로부터 local branch 를 최신으로 업데이트 하는 방법, pull/rebase의 이해
4. 수정 반영 방법, Git의 Staging area 개념과 작업 방법, add/commit 의 이해, commit -s 옵션
5. Commit 을 수정하는 방법, commit –amend 의 이해
6. Push 방법 – Gerrit의 refs/for/* 개념 이해, push의 이해, push 시의 refs spec 이해
7. Log를 확인하는 방법, log
8. Commit 간 차이(diff)를 확인하는 방법, diff
9. 특정 시점의 소스로 돌아가는 방법, reset
10. 특정 소스 파일을 특정 시점으로 되돌리는 방법, checkout
11. Backout 방법, revert
12. local 브랜치를 만드는 방법, branch
13. remote 브랜치나 local 브랜치로 local 소스를 만드는 방법, checkout
14. cherry-pick 의 이해, cherry-pick
15. patch 파일 만들기와 패치 적용 방법, , format-patch/am
16. merge 방법 및 merge commit이 무엇인지, merge
17. rebase 나 merge 시의 conflict 해결 방법

* gerrit
1. 그룹의 정의 및 권한 이해
2. Verify 방법 – Verify 의 의미 이해
3. Review 방법 – Inline comments 작성 및 cover message 작성(+ 한글 작성 가능 알림)
4. Gerrit 에서 cherry-pick 하기
5. Gerrit 에서 checkout 하기
6. Gerrit 에서 같은 Change의 Patch set 업데이트 하기
7. Submit 시의 동작 이해

개발 환경 개선 Git + Gerrit + checkpatch + cleanpatch

원래 나한테 좀 맞지 않던 카메라 개발에서 벗어나서 요즘 좀 재밌는 걸 하고 있다.
개발 업무를 살짝 벗어나서 SCM 업무를 하고 있는데, 내가 옳다고 생각하는 방향으로 부서 전체를 바꾸고 있어서 좀 재미나다. 회사 전체를 바꿀 수 있으면 더 재미날 것 같지만, 그건 이후의 일이고..

아무튼 요약하면 구글에서 NexusS 개발을 하면서 썼던 git + gerrit 시스템을 적용하고, 여기에 코딩룰 자동 오류 보고 + 코딩 룰 자동 오류 수정 + 수정본 자동 업로드를 구축 중이다. 여러 가지 것들을 조합해서 만들어 내는 개발환경 개선 작업은 신난다.

1. 기존의 불편한 Centeralized VCS 툴을 벗어나 DVCS를 사용해 여러 브랜치의 Integration 작업의 어려움을 줄이고, 같은 패치를 여러 곳에 적용하기 쉽게 만들고,
2. 코드 리뷰 시스템을 통해 좋은 코드를 함께 말할 수 있는 장을 만들고, 코드 개선을 양지로 끌어내고, 코딩 룰에 대해 생각하게 하고, 코드의 구조에 대해 생각하게 하고, 후배 개발자에게 선배 개발자의 지식을 전달할 수 있는 체계를 만들고,
3. 코딩 룰의 자동 체크를 통해 리뷰어의 노력을 덜 들이게 하고, 개발자의 모든 코드의 코딩룰을 검사하도록 하고, 수정하도록 요구하며,
4. 구조 개선 같은 복잡한 것까지는 아니더라도 체크한 패치가 오류가 있으면 간단한 코딩 룰 등은 자동으로 수정해서 바로 업로드 하여 개발자들의 코딩 룰 등 간단한 수정에 드는 노력을 줄인다.

여기에 기존 시스템(빌드, 배포 등)과의 호환성 유지를 위한 작업까지.. 아직은 사내 모든 부서가 내가 구축하는 것을 따르고 있지는 않기 때문에..

개발 생산성 향상이라는게 말만큼 거창한게 아니다. 개선에 개선을 거듭해 쓸데없는 일을 줄이고 줄여, 더이상 뺄 게 없는 프로세스를 만들어 내는 거다.

위에 것이 어떻게 가능하냐. git + gerrit + jenkins + Linux kernel의 checkpatch.pl, Linux kernel의 cleanpatch + Linux shell의 여러 utility + 손수 제작 스크립트(bash, perl 등)를 조합하면 된다.

딴데도 이렇게 하고 있는 곳이 있을까? 내맘대로 세계 최초라 주장하련다. ㅋㅋㅋㅋ