일상 속의 행복

커널 소스 관련...

2009-11-04T12:53:37Z

다들 아는 것이겠지만 자주 잊어먹기 때문에 정리한다.

리눅스 커널을 받으려면 http://www.kernel.org/

안드로이드 소스 관리를 보려면 http://android.git.kernel.org/

안드로이드는 당연히 gitweb이다

안드로이드의 공식적인 커널을 받으려면 kernel/common.git으로 받으면 된다.

$git clone git://android.git.kernel.org/kernel/common.git

default branch는 android-2.6.27 이다.

Donut 버젼에서 권장하는 branch는 android-2.6.29 이다

이를 위해서는 다운로드 받은 상태에서 다음과 같이 한다.

$git checkout -b android-2.6.29

안드로이드 초기화 (Init 프로세스 코드 분석)

2009-10-26T17:53:27Z

안드로이드의 초기화 과정 중 Init 프로세스를 생성하고 init 프로세스가 동작하는 과정에 대하여 정리한다.

Init 프로세스는 부팅 과정에서 커널이 생성하는 첫번째 프로세스로 PID는 1이다.

리눅스 커널의 부팅 과정을 보면 알겠지만 다음 과정에서 생성된다.

/kernel/init/main.c 파일을 참조하면 다음과 같은 초기화 과정을 거친다.

start_kernel()

rest_init()

kernel_init()

init_post()

init_post()에서 init 프로세스를 생성하는데, 이를 위해서 ramdisk_execute_command를 kernel_init()에서 "/init" 으로 설정하고 access 여부를 확인한다. run_init_process()에서는 입력된 파일명을 실행하는 역활만을 한다.

static int noinline init_post(void)
{
        free_initmem();
        unlock_kernel();
        mark_rodata_ro();
        system_state = SYSTEM_RUNNING;
        numa_default_policy();

if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
printk(KERN_WARNING "Warning: unable to open an initial console.\n");

(void) sys_dup(0);
(void) sys_dup(0);

current->signal->flags |= SIGNAL_UNKILLABLE;

        if (ramdisk_execute_command) {
                run_init_process(ramdisk_execute_command);
                printk(KERN_WARNING "Failed to execute %s\n",
                                ramdisk_execute_command);
        }

        /*
         * We try each of these until one succeeds.
         *
         * The Bourne shell can be used instead of init if we are
         * trying to recover a really broken machine.
         */
        if (execute_command) {
                run_init_process(execute_command);
                printk(KERN_WARNING "Failed to execute %s. Attempting "
                                        "defaults...\n", execute_command);
        }
        run_init_process("/sbin/init");
        run_init_process("/etc/init");
        run_init_process("/bin/init");
        run_init_process("/bin/sh");

panic("No init found. Try passing init= option to kernel.");
}

이후에 /sbin/init, /etc/init, /bin/init, /bin/sh 를 실행하는 코드가 있는데 안드로이드의 경우 실제 이와 관련된 파일이 없기 때문에 위의 과정으로만 처리가 된다.

안드로이드에서 init 프로세스와 관련된 코드는 /system/core/init/init.c 에 있다. init 프로세스가 하는 중요한 작업 중 하나는 init.rc 파일을 처리하는 것이다.

안드로이드에서 기본적으로 사용하는 init.rc 파일은 /system/core/rootdir/init.rc 파일이다. /system/core/rootdir/Android.mk 파일을 보면 init.rc 파일을 target 디렉토리로 복사하도록 하고 있다.

init 프로세스의 기본 기능을 다시 한번 정리하면 다음과 같다.

1) SIGCHLD signal 처리

2) rc 파일 처리 (init.rc 와 init.xxx.rc)

3) 디바이스 초기화와 관리

4) 기본 property 설정

이중 rc 파일 처리를 보면 다음과 같다.

INFO("reading config file\n");
parse_config_file("/init.rc");

    /* pull the kernel commandline and ramdisk properties file in */
    qemu_init();
    import_kernel_cmdline(0);

    get_hardware_name();
    snprintf(tmp, sizeof(tmp), "/init.%s.rc", hardware);
    parse_config_file(tmp);

처음 init.rc 파일을 분석해서 서비스(Service) 리스트와 액션(Action) 리스트를 만든다.

다음으로 import_kernel_cmdline()을 호출해서 필요한 내용을 전역 변수에 저장한다. 이를 보면 /proc/cmdline을 읽어와서 이를 분석하여 저장하는데 /proc/cmdline에 저장된 내용은 kernel 컴파일시 CONFIG_CMDLINE에 정의한 문자열 (/kernel/.config 파일 참조)이다.

static void import_kernel_cmdline(int in_qemu)
{
    char cmdline[1024];
    char *ptr;
    int fd;

    fd = open("/proc/cmdline", O_RDONLY);
    if (fd >= 0) {
        int n = read(fd, cmdline, 1023);
        if (n < 0) n = 0;

/* get rid of trailing newline, it happens */
if (n > 0 && cmdline[n-1] == '\n') n--;

        cmdline[n] = 0;
        close(fd);
    } else {
        cmdline[0] = 0;
    }

    ptr = cmdline;
    while (ptr && *ptr) {
        char *x = strchr(ptr, ' ');
        if (x != 0) *x++ = 0;
        import_kernel_nv(ptr, in_qemu);
        ptr = x;
    }

/* don't expose the raw commandline to nonpriv processes */
chmod("/proc/cmdline", 0440);
}

arm의 경우는 CONFIG_CMDLINE으로 정의된 문자열을 /kernel/arch/arm/kernel/setup.c 에서 처리한다.

하여간에 import_kernel_cmdline()을 보면 /proc/cmdline의 내용을 읽어와서 import_kernel_nv()를 이용해서 전역 변수(console, bootmode, serialno, baseband, carrier, bootloader, hardware)에 저장한다.

내 안드로이드 환경에서는 CONFIG_CMDLINE의 문자열은 다음과 같다. androidboot.hardware만 정의하기 때문에 전역 변수 hardware 값만 설정된다.

CONFIG_CMDLINE="root=/dev/ram rw initrd=0x40600000,0x400000 init=/init console=ttySAC0 mem=200M androidboot.hardware=tcc92xx"

마지막으로 get_hardware_name()을 호출해서 hardware 이름(xxx라고 가정)을 얻어낸 후, init.xxx.rc 파일을 분석해서 역시 서비스 리스트와 액션 리스트를 만든다. init.rc가 안드로이드에서 기본적으로 수행해야할 서비스들을 정리한다고 하면 init.xxx.rc에는 하드웨어 의존적인 초기화 과정을 만들어 두어야 한다.

get_hardware_name()을 보면 /proc/cpuinfo의 내용을 읽어서 전역 변수 hardware와 revision을 다시 설정하는데 왜 다시 처리하는지는 모르겠다.

일단 init,rc와 init.xxx.rc (내 보드에서는 init.tcc92xx.rc)을 분석해서 서비스 리스트와 액션 리스트를 만드는 것은 parse_config_file()이 한다. 이 함수는 /system/core/init/parser.c 에 있다.

init.rc 파일은 on init 에서 수행해야 하는 액션 리스트와 on boot에서 수행해야 하는 액션 리스트가 있다.

on init

sysclktz 0

loglevel 3

# setup the global environment
    export PATH /sbin:/system/sbin:/system/bin:/system/xbin
    export LD_LIBRARY_PATH /system/lib
    export ANDROID_BOOTLOGO 1
    export ANDROID_ROOT /system
    export ANDROID_ASSETS /system/app
    export ANDROID_DATA /data
    export EXTERNAL_STORAGE /sdcard

# Backward compatibility
symlink /system/etc /etc

# create mountpoints and mount tmpfs on sqlite_stmt_journals
    mkdir /sdcard 0000 system system
    mkdir /system
    mkdir /data 0771 system system
    mkdir /cache 0770 system cache
    mkdir /sqlite_stmt_journals 01777 root root
    mount tmpfs tmpfs /sqlite_stmt_journals size=4m

mount rootfs rootfs / ro remount

    write /proc/sys/kernel/panic_on_oops 1
    write /proc/sys/kernel/hung_task_timeout_secs 0
    write /proc/cpu/alignment 4
    write /proc/sys/kernel/sched_latency_ns 10000000
    write /proc/sys/kernel/sched_wakeup_granularity_ns 2000000
    write /proc/sys/kernel/sched_compat_yield 1

# Create cgroup mount points for process groups
    mkdir /dev/cpuctl
    mount cgroup none /dev/cpuctl cpu
    chown system system /dev/cpuctl
    chown system system /dev/cpuctl/tasks
    chmod 0777 /dev/cpuctl/tasks

......

# mount mtd partitions

    # Mount /system rw first to give the filesystem a chance to save a checkpoint
    mount yaffs2 mtd@system /system
    mount yaffs2 mtd@system /system ro remount

......

# create basic filesystem structure
    mkdir /data/misc 01771 system misc
    mkdir /data/misc/hcid 0770 bluetooth bluetooth
    mkdir /data/misc/keystore 0770 keystore keystore

on boot
# basic network init
    ifup lo
    hostname localhost
    domainname localdomain

# set RLIMIT_NICE to allow priorities from 19 to -20
setrlimit 13 40 40

# Define the oom_adj values for the classes of processes that can be
# killed by the kernel. These are used in ActivityManagerService.
    setprop ro.FOREGROUND_APP_ADJ 0
    setprop ro.VISIBLE_APP_ADJ 1
    setprop ro.SECONDARY_SERVER_ADJ 2
    setprop ro.BACKUP_APP_ADJ 2
    setprop ro.HOME_APP_ADJ 4
    setprop ro.HIDDEN_APP_MIN_ADJ 7
    setprop ro.CONTENT_PROVIDER_ADJ 14
    setprop ro.EMPTY_APP_ADJ 15

# Define the memory thresholds at which the above process classes will
# be killed. These numbers are in pages (4k).
    setprop ro.FOREGROUND_APP_MEM 1536
    setprop ro.VISIBLE_APP_MEM 2048
    setprop ro.SECONDARY_SERVER_MEM 4096
    setprop ro.BACKUP_APP_MEM 4096
    setprop ro.HOME_APP_MEM 4096
    setprop ro.HIDDEN_APP_MEM 5120
    setprop ro.CONTENT_PROVIDER_MEM 5632
    setprop ro.EMPTY_APP_MEM 6144

# Write value must be consistent with the above properties.
# Note that the driver only supports 6 slots, so we have HOME_APP at the
# same memory level as services.
write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15

    write /proc/sys/vm/overcommit_memory 1
    write /proc/sys/vm/min_free_order_shift 4
    write /sys/module/lowmemorykiller/parameters/minfree 1536,2048,4096,5120,5632,6144

# Set init its forked children's oom_adj.
write /proc/1/oom_adj -16

    # Permissions for System Server and daemons.
    chown radio system /sys/android_power/state
    chown radio system /sys/android_power/request_state
    chown radio system /sys/android_power/acquire_full_wake_lock
    chown radio system /sys/android_power/acquire_partial_wake_lock
    chown radio system /sys/android_power/release_wake_lock
    chown radio system /sys/power/state
......

# Define TCP buffer sizes for various networks
#   ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax,
    setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208
    setprop net.tcp.buffersize.wifi    4095,87380,110208,4096,16384,110208
    setprop net.tcp.buffersize.umts    4094,87380,110208,4096,16384,110208
    setprop net.tcp.buffersize.edge    4093,26280,35040,4096,16384,35040
    setprop net.tcp.buffersize.gprs    4092,8760,11680,4096,8760,11680

분석되어 리스트로 만들어진 액션들은 다음 코드들에 의하여 실행된다. (/system/core/init/main.c)

int main(int argc, char **argv)
{

action_for_each_trigger("early-init", action_add_queue_tail);
drain_action_queue();

......

         /* execute all the boot actions to get us started */
    action_for_each_trigger("init", action_add_queue_tail);
    drain_action_queue();

......

    /* execute all the boot actions to get us started */
    action_for_each_trigger("early-boot", action_add_queue_tail);
    action_for_each_trigger("boot", action_add_queue_tail);
    drain_action_queue();

}

코드를 보면 early-init, init, early-boot, boot 에 따른 액션 리스트를 실행하는데, 안드로이드에서 사용하는 init.rc에 early-init과 early-boot가 없기 때문에 init과 boot에 해당하는 액션만 실행된다.

init은 주로 전역 변수 초기화, 마운트 포인트(mount point) 생성, MTD 파티션 마운트, 기본적인 파일 시스템 구조를 생성하며,

boot는 네트웍을 초기화 하며, 접근 권한 등을 설정하고, APP group의 메모리 사용량을 설정한다.

서비스의 경우는 class_start default 로부터 정의된다.

class_start default

## Daemon processes to be run by init.
##
service console /system/bin/sh
console

# adbd is controlled by the persist.service.adb.enable system property
service adbd /sbin/adbd
disabled

# adbd on at boot in emulator
on property:ro.kernel.qemu=1
start adbd

......

service servicemanager /system/bin/servicemanager
    user system
    critical
    onrestart restart zygote
    onrestart restart media

서비스들을 정의하는 방법은 다음과 같다.

service []

.....

즉 위의 예를 보면 servicemanager는 /system/bin/servicemanager를 실행해야 하며 user system, critical과 onstart 옵션을 가진다는 것을 알 수 있다. critical은 안드로이드의 운영 정책으로 4번 오류 발생시 reboot한다는 의미라고 한다. onrestart는 해당 서비스가 재시작되면 다음의 서비스를 다시 시작하라는 말이다. 즉 servicemanager가 재시작되면 zygote와 media도 다시 시작해야 한다.

(/system/core/init/readme.txt 참조)

서비스 리스트들은 어떻게 시작될까?

이 부분에 대해서는 다음 포스팅을 일단 참조한다. (http://andstudy.springnote.com/pages/3872497)

일단 init 프로세스가 동작하면 루프를 돌면서 restart_process(0를 호출하는데 여기에서 처리되는 것 같다. 좀 더 정리하면 좋겠지만 다른 일로 나중에 정리한다.

for(;;) {
int nr, i, timeout = -1;

for (i = 0; i < fd_count; i++)
ufds[i].revents = 0;

drain_action_queue();
restart_processes();

        if (process_needs_restart) {
            timeout = (process_needs_restart - gettime()) * 1000;
            if (timeout < 0)
                timeout = 0;
        }

#if BOOTCHART
        if (bootchart_count > 0) {
            if (timeout < 0 || timeout > BOOTCHART_POLLING_MS)
                timeout = BOOTCHART_POLLING_MS;
            if (bootchart_step() < 0 || --bootchart_count == 0) {
                bootchart_finish();
                bootchart_count = 0;
            }
        }
#endif
        nr = poll(ufds, fd_count, timeout);
        if (nr <= 0)
            continue;

        if (ufds[2].revents == POLLIN) {
            /* we got a SIGCHLD - reap and restart as needed */
            read(signal_recv_fd, tmp, sizeof(tmp));
            while (!wait_for_one_process(0))
                ;
            continue;
        }

if (ufds[0].revents == POLLIN)
handle_device_fd(device_fd);

        if (ufds[1].revents == POLLIN)
            handle_property_set_fd(property_set_fd);
        if (ufds[3].revents == POLLIN)
            handle_keychord(keychord_fd);
    }

init.rc에 의해서 수행되는 서비스는 다음과 같다.

console, abdb, servicemanager, vold, nexus(?), debuggerd, ril-daemon, zygote, media, bootsound, bootanim, dbus, hcid, hfag, hsag, installd, flash_recovery, racoon, httpd, keystore

정적 디바이스 드라이버 초기화 (등록)

2009-10-25T19:59:12Z

디바이스 드라이버를 등록하는 과정을 알아보기 위해서는 커널 초기화 과정을 따라갈 필요가 있다.

사용하는 CPU가 arm인 경우 초기화를 담당하는 어셈블 코드에서 C 코드로의 이동은

/kernel/arch/arm/kernel/head-common.S 파일의 __map_switched 에서 start_kernel()로 분기하면서 리눅스 커널의 초기화 과정이 시작된다.

__mmap_switched:
adr r3, __switch_data + 4

        ldmia   r3!, {r4, r5, r6, r7}
        cmp     r4, r5                          @ Copy data segment if needed
1:      cmpne   r5, r6
        ldrne   fp, [r4], #4
        strne   fp, [r5], #4
        bne     1b

        mov     fp, #0                          @ Clear BSS (and zero fp)
1:      cmp     r6, r7
        strcc   fp, [r6],#4
        bcc     1b

        ldmia   r3, {r4, r5, r6, r7, sp}
        str     r9, [r4]                        @ Save processor ID
        str     r1, [r5]                        @ Save machine type
        str     r2, [r6]                        @ Save atags pointer
        bic     r4, r0, #CR_A                   @ Clear 'A' bit
        stmia   r7, {r0, r4}                    @ Save control register values
        b       start_kernel

start_kernel()은 /kernel/init/main.c 에서 선언하고 있으며 주로 Hardware와 밀접한 내용들을 초기화 하는 과정을 포함하며 리눅스 커널과 관련된 대부분의 초기화 과정이 여기에서 이루어 진다.

start_kernel()의 제일 마지막은 rest_init()을 호출한다.

asmlinkage void __init start_kernel(void)
{
char * command_line;
extern struct kernel_param __start___param[], __stop___param[];

......

acpi_early_init(); /* before LAPIC and SMP init */

/* Do the rest non-__init'ed, we're now alive */
rest_init();
}

리눅스 커널이 동작하면 /init 프로세스와 kthreadd 프로세스가 제일 처음 실행되게 되는데 이를 시작하는 것이 rest_init()이다.

static void noinline __init_refok rest_init(void)
__releases(kernel_lock)
{
int pid;

        kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
        numa_default_policy();
        pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);
        kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns);
        unlock_kernel();

        /*
         * The boot idle thread must execute schedule()
         * at least once to get things moving:
         */
        init_idle_bootup_task(current);
        preempt_enable_no_resched();
        schedule();
        preempt_disable();

/* Call into cpu_idle with preempt disabled */
cpu_idle();
}

rest_init()에서 구동되는 kernel_init() 에서는 부팅 과정에서 커널이 생성하는 첫번째 프로세스인 /init을 생성하기 직전에 do_basic_setup()을 호출하여 정적인 디바이스 드라이버 파일을 초기화(등록) 하게 된다.

static int __init kernel_init(void * unused)
{
        lock_kernel();
        /*
         * init can run on any cpu.
         */
        set_cpus_allowed_ptr(current, CPU_MASK_ALL_PTR);
        /*
         * Tell the world that we're going to be the grim
         * reaper of innocent orphaned children.
         *
         * We don't want people to have to make incorrect
         * assumptions about where in the task array this
         * can be found.
         */
        init_pid_ns.child_reaper = current;

cad_pid = task_pid(current);

smp_prepare_cpus(setup_max_cpus);

do_pre_smp_initcalls();

smp_init();
sched_init_smp();

cpuset_init_smp();

do_basic_setup();

        /*
         * check if there is an early userspace init. If yes, let it do all
         * the work
         */

if (!ramdisk_execute_command)
ramdisk_execute_command = "/init";

        if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
                ramdisk_execute_command = NULL;
                prepare_namespace();
        }

        /*
         * Ok, we have completed the initial bootup, and
         * we're essentially up and running. Get rid of the
         * initmem segments and start the user-mode stuff..
         */
        init_post();
        return 0;
}

do_basic_setup()에서 workqueue, driver, irq_proc 등을 호출하고 마지막으로 do_initcalls()를 호출한다. (do_pre_smp_initcalls() 함수고 do_basic_setup() 과 유사한 일을 수행한다)

static void __init do_basic_setup(void)
{
        rcu_init_sched(); /* needed by module_init stage. */
        /* drivers will send hotplug events */
        init_workqueues();
        usermodehelper_init();
        driver_init();
        init_irq_proc();
        do_initcalls();
}

do_initcalls()은 for 문을 이용해서 do_one_initcall()을 호출하게 된다.

extern initcall_t __initcall_start[], __initcall_end[], __early_initcall_end[];

static void __init do_initcalls(void)
{
initcall_t *call;

for (call = __early_initcall_end; call < __initcall_end; call++)
do_one_initcall(*call);

/* Make sure there is no pending stuff from the initcall sequence */
flush_scheduled_work();
}

static void __init do_pre_smp_initcalls(void)
{
initcall_t *call;

for (call = __initcall_start; call < __early_initcall_end; call++)
do_one_initcall(*call);
}

int do_one_initcall(initcall_t fn)

{
        int count = preempt_count();
        ktime_t t0, t1, delta;
        char msgbuf[64];
        int result;

        if (initcall_debug) {
                printk("calling %pF\n", fn);
                t0 = ktime_get();
        }

result = fn();

......

}

여기서 보면 __early_initcall_end에서 __initcall_end 사이에 등록된 함수들을 호출하는 것을 알 수 있다.

이들은 보통 CPU에 따라서 vmlinux.lds.S 파일에 정의되어 있다. arm의 경우를 보면 /kernel/arch/arm/kernel/vmlinux.lds.S 파일에 정의되어 있다.

       .init : {                       /* Init code and data           */
                        INIT_TEXT
                _einittext = .;
                __proc_info_begin = .;
                        *(.proc.info.init)
                __proc_info_end = .;
                __arch_info_begin = .;
                        *(.arch.info.init)
                __arch_info_end = .;
                __tagtable_begin = .;
                        *(.taglist.init)
                __tagtable_end = .;
                . = ALIGN(16);
                __setup_start = .;
                        *(.init.setup)
                __setup_end = .;
                __early_begin = .;
                        *(.early_param.init)
                __early_end = .;
                __initcall_start = .;
                        INITCALLS
                __initcall_end = .;

.....

}

INITCALLS는 /kernel/include/asm-generic/vmlinux.lds.h 에 선언되어 있는데 이를 이용하여 /kernel/arch/arm/kernel/vmlinux.lds.S 의 내용을 다시 정리하면 다음과 같다.

__initcall_start = .;
        *(.initcallearly.init)                                          \
        VMLINUX_SYMBOL(__early_initcall_end) = .;                       \
        *(.initcall0.init)                                              \
        *(.initcall0s.init)                                             \
        *(.initcall1.init)                                              \
        *(.initcall1s.init)                                             \
        *(.initcall2.init)                                              \
        *(.initcall2s.init)                                             \
        *(.initcall3.init)                                              \
        *(.initcall3s.init)                                             \
        *(.initcall4.init)                                              \
        *(.initcall4s.init)                                             \
        *(.initcall5.init)                                              \
        *(.initcall5s.init)                                             \
        *(.initcallrootfs.init)                                         \
        *(.initcall6.init)                                              \
        *(.initcall6s.init)                                             \
        *(.initcall7.init)                                              \
        *(.initcall7s.init)

__initcall_end = .;

이 의미는 특정한 서브 섹션에 함수 포인터를 등록하기 위한 코드이다. 실제로 /kernel/include/linux/init.h 파일을 보면 이를 위한 매크로가 선언되어 있다.

#define __define_initcall(level,fn,id) \
static initcall_t __initcall_##fn##id __used \
__attribute__((__section__(".initcall" level ".init"))) = fn

/*
* Early initcalls run before initializing SMP.
*
* Only for built-in code, not modules.
*/
#define early_initcall(fn) __define_initcall("early",fn,early)

/*
* A "pure" initcall has no dependencies on anything else, and purely
* initializes variables that couldn't be statically initialized.
*
* This only exists for built-in code, not for modules.
*/
#define pure_initcall(fn) __define_initcall("0",fn,0)

#define core_initcall(fn)               __define_initcall("1",fn,1)
#define core_initcall_sync(fn)          __define_initcall("1s",fn,1s)
#define postcore_initcall(fn)           __define_initcall("2",fn,2)
#define postcore_initcall_sync(fn)      __define_initcall("2s",fn,2s)
#define arch_initcall(fn)               __define_initcall("3",fn,3)
#define arch_initcall_sync(fn)          __define_initcall("3s",fn,3s)
#define subsys_initcall(fn)             __define_initcall("4",fn,4)
#define subsys_initcall_sync(fn)        __define_initcall("4s",fn,4s)
#define fs_initcall(fn)                 __define_initcall("5",fn,5)
#define fs_initcall_sync(fn)            __define_initcall("5s",fn,5s)
#define rootfs_initcall(fn)             __define_initcall("rootfs",fn,rootfs)
#define device_initcall(fn)             __define_initcall("6",fn,6)
#define device_initcall_sync(fn)        __define_initcall("6s",fn,6s)
#define late_initcall(fn)               __define_initcall("7",fn,7)
#define late_initcall_sync(fn)          __define_initcall("7s",fn,7s)

예를 들어 내가 Board 동작에 필요한 기본적인 드라이버들을 하나의 파일에 정의해서 일괄적으로 platform에 등록하는 함수를 만들어 두었다면 커널 초기화에 사용하기 위해서 마지막에 .initcall 섹센에 등록해야 한다.

내가 사용하는 TCC92xx 보드의 device.c 파일에 위와 관련된 코드(/kernel/arch/arm/mach-tcc92x/devices.c)가 있다.

static int __init tcc9200_init_devices(void)
{
platform_add_devices(devices, ARRAY_SIZE(devices));

return 0;
}

arch_initcall(tcc9200_init_devices);

위와 같이 arch_initcall 매크로를 이용해서 tcc9200_init_devices를 .initcall3.init 섹션에 tcc9200_init_device 함수 포인터를 등록하게 된다. 이는 위에서 설명한 것처럼 do_initcalls() 에서 섹션에 등록된 순서대로 호출되게 된다.

다른 예로 보면 arm의 경우 /kernel/arch/arm/kernel/time.c 파일에서 LED 제어와 sysfs를 위한 device를 등록한다.

static int __init leds_init(void)
{
        int ret;
        ret = sysdev_class_register(&leds_sysclass);
        if (ret == 0)
                ret = sysdev_register(&leds_device);
        if (ret == 0)
                ret = sysdev_create_file(&leds_device, &attr_event);
        return ret;
}

device_initcall(leds_init);

static int __init timer_init_sysfs(void)
{
        int ret = sysdev_class_register(&timer_sysclass);
        if (ret == 0) {
                system_timer->dev.cls = &timer_sysclass;
                ret = sysdev_register(&system_timer->dev);
        }

return ret;
}

device_initcall(timer_init_sysfs);

일반적인 디바이스 드라이버의 경우도 각각의 디바이스 드라이버 파일을 마지막에 보면 module_init()과 module_exit() 매크로로 커널에 모듈을 적재하고 제거할 때 호출하는 함수를 지정하는 매크로가 있다. 보통 디바이스 드라이버는 정적으로도 커널에 링크시킬 수 있고 모듈 형태로 사용할 수도 있는데 module_init 매크로에 대한 정의를 /kernel/include/linux/init.h 에서 보면 다음과 같이 두가지로 정의한다.

MODULE로 정의되지 않은 경우

#define device_initcall(fn) __define_initcall("6",fn,6)

......

#define __initcall(fn) device_initcall(fn)

......

/**
* module_init() - driver initialization entry point
* @x: function to be run at kernel boot time or module insertion
*
* module_init() will either be called during do_initcalls() (if
* builtin) or at module insertion time (if a module). There can only
* be one per module.
*/
#define module_init(x) __initcall(x);

즉 moudle_init 매크로는 디바이스 드라이버를 모듈로 컴파일 하지 않으면 device_initcall에 의해서 .initcall7.init 섹션에 등록되어 커널 초기화 과정에서 등록하게 된다.

MODULE로 정의되어 있는 경우는 다음과 같다.

/* Each module must use one module_init(). */
#define module_init(initfn)                                     \
        static inline initcall_t __inittest(void)               \
        { return initfn; }                                      \
        int init_module(void) __attribute__((alias(#initfn)));

/* This is only required if you want to be unloadable. */
#define module_exit(exitfn)                                     \
        static inline exitcall_t __exittest(void)               \
        { return exitfn; }                                      \
        void cleanup_module(void) __attribute__((alias(#exitfn)));

위의 경우는 __inittest()라는 초기화 함수 포인터를 넘겨주는 static 함수를 만들고 이를 모듈 드라이버 로딩 과정에서 호출할 수 있게 해준다.

proc 디렉토리

2009-10-24T13:37:48Z

리눅스의 기본적인 디렉토리 구조에 대한 설명은 다음을 참조한다.

http://mnslaboratory.springnote.com/pages/755516

리눅스에서 proc 디렉토리는 시스템의 여러 실시간 정보들이 디렉토리와 파일 형태로 저장되어 있다. 리눅스에서 proc와 dev는 가상 파일 시스템에 위치하는 가상 디렉토리로 실제 물리적인 디스크에 존재하는 것은 아니다.(즉 메모리에 저장된다)

proc에 대한 내용은 다음을 주로 참조하여 정리하였다.

http://www.heyjinism.com/open_class/2913

http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/system_programing/proc/GetSMSInfo

proc 디렉토리로 이동한 후, ls로 내용을 보면 문자로 시작하는 것과 번호로 시작하는 것으로 크게 구분할 수 있다.

시스템 정보를 확인할 수 있는 것 위주로 정리한다. 파일의 경우 대부분 cat 으로 내용을 확인할 수 있다.

정리한 내용에서 예로 보여주는 것들은 사용중인 안드로이드 데모 보드에서 나오는 내용이다.

/proc/cpuinfo

이름 그대로 CPU 정보를 보여준다.

Processor       : ARMv6-compatible processor rev 6 (v6l)
BogoMIPS        : 719.25
Features        : swp half thumb fastmult vfp edsp java
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 6
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown : format C
Cache format    : Harvard
I size          : 16384
I assoc         : 4
I line length   : 32
I sets          : 128
D size          : 16384
D assoc         : 4
D line length   : 32
D sets          : 128

Hardware        : Telechips TCC9200 Demo Board
Revision        : 0000
Serial          : 0000000000000000

BegoMIPS는 MIPS 정보를 보여준다. 즉 현재 CPU는 719.25 MIPS란 의미이며 다 알겠지만 초당 719.25 백만개의 명령어를 실행할 수 있다는 의미이다.

이 외에도 Cache 메모리와 관련된 정보나 Board 정보도 간단하게 확인이 가능하다.

/proc/devices

시스템이 사용하는 디바이스 정보를 보여준다.

Character devices:
1 mem
4 /dev/vc/0
4 tty
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
14 sound
29 fb
81 video4linux
89 i2c
90 mtd
108 ppp
116 alsa
128 ptm
136 pts
153 spi
180 usb
189 usb_device
196 vpu
197 tdmb_tuner
198 jpeg
199 graphic
200 scaler
201 scaler1
202 overlay
204 tcc-uart
216 rfcomm
244 bl
246 tcc_intr
251 mali
252 tcc-tsif
253 usbmon

254 rtc

Block devices:
1 ramdisk
7 loop
31 mtdblock
44 ftl
93 nftl
179 mmc

크게 Char형 장치와 Block형 장치로 구분하여 보여줌을 알 수 있다.

앞에 숫자는 디바이스 드라이버의 Major 넘버이다. 현재 시스템에서 사용하는 디바이스 드라이버들은 /dev 에서 관리하는데 위의 정보와 /dev 정보를 비교해 보면 같다는 것을 알수 있다. (Minor 넘버까지 표시되므로 dev 내용이 더 많기는 하다)

/proc/filesystems

커널이 지원하는 파일 시스템의 정보를 보여준다.

nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   debugfs
nodev   sockfs
nodev   pipefs
nodev   anon_inodefs
nodev   tmpfs
nodev   inotifyfs
nodev   configfs
nodev   devpts
            ext2
nodev   ramfs
            vfat
            yaffs
            yaffs2

/proc/dma

DMA 채널 정보를 보여준다고 하는데 현재 내 안드로이드 환경에서는 존재하지 않는다.

/proc/interrupts

인터럽트 정보를 보여준다. 즉 인터럽트 번호에 어떤 인터럽트가 연결되어 있는지를 알 수 있다.

           CPU0
1:     510168         IRQ TC1_timer
14:          0         IRQ tsc2003_ts
19:     292363         IRQ TCC_LCD
24:        108         IRQ Mali 200 (GX525)
25:        108         IRQ MALI_GP2
26:          0         IRQ Mali MMU
34:          0         IRQ hdmi, cec, spdif
43:          0         IRQ tcc-rtc
44:         57         IRQ TCC_SD_SLOT0
45:          0         IRQ TCC_SD_SLOT1
48:          0         IRQ tcc-udc
64:       2836    IRQ_UART uart0
71:          0    IRQ_GPSB tsif
Err:          0

/proc/ioports

사용하고 있는 입출력 포트 정보를 보여준다. 현재 내 안드로이드 환경에서는 아무 내용이 없다.

이는 x86 계열처럼 메모리 공간과 I/O 공간이 분리되어 있는 경우에 볼 수 있는 정보이기 떄문이다.

현재 CPU가 ARM 계열이기 때문에 내용이 없는 것이다.

/proc/iomem

I/O 장치들이 사용하고 있는 메모리 번지를 보여준다. 68x 계열이나 ARM 계열들은 memory mapped I/O를 지원하기 때문에 이에 대한 정보를 확인할 수 있다.

00000064-00000064 : tcc-i2c
00000064-00000064 : tcc-i2c
40000000-4c7fffff : System RAM
40120000-4045bfff : Kernel text
4045c000-40520da5 : Kernel data
4dc00000-4fbfffff : Mali_SDRAM remapped to baseboard
f0000000-f00010ef : Mali 200 (GX525)
f0002000-f0002097 : MALI_GP2
f0003000-f0003023 : Mali MMU
f0102000-f0102030 : tcc-keypad
f0405000-f0405040 : tcc-i2c
f0530000-f05300c0 : tcc-tsc2003-ts
f0530000-f0530040 : tcc-i2c
f0532000-f05320ff : tcc9200-uart.0
f0532100-f05321ff : tcc9200-uart.1
f0532200-f05322ff : tcc9200-uart.2
f0532300-f05323ff : tcc9200-uart.3
f0532400-f05324ff : tcc9200-uart.4
f0532500-f05325ff : tcc9200-uart.5
f0550000-f0550100 : tcc-udc.0
f05a0000-f05a00ff : tcc-mmc0.0
f05a0200-f05a02ff : tcc-mmc1.1
f05f2000-f05f20ff : tcc-rtc
f05f4000-f05f404c : tcc9200-adc.0

/proc/kcore

커널 메모리 이미지를 보여준다고 하는데 현재 내 안드로이드 환경에서는 존재하지 않는다.

/proc/kmsg

커널이 동작 중 중요한 이벤트가 생기면 출력되는 메시지를 보여준다. 보통 커널에서 printk를 사용해서 콘솔에 출력하도록 한 메시지를 말한다. 이런 메시지를 확인하는 명령으로 dmesg가 있다. 원래 dmesg를 실행하면 /var/log/dmesg 의 내용을 보여준다고 하는데 내 안드로이드 환경에서는 이 파일이 존재하지 않는다. 내용을 확인해 보면 dmegs 명령을 실행한 경우와 /proc/kmsg 를 출력한 경우와 같다. 따라서 이 부분은 커널 버젼에 따라서 달라진 것으로 보인다.

/proc/ksyms

/proc/kallsyms

모듈이 참조할 수 있는 커널 내부의 함수나 변수의 심볼 정보를 가지고 있다. 이는 모듈 개념을 지원하기 위한 중요한 정보이다. 일반적으로 linux에서는 /proc/ksyms가 심볼 정보를 가지고 있다고 하나 안드로이드에서는 /proc/kallsysms를 사용한다(정확하게는 커널 버젼에 따라 다른 이름을 사용하는 것 같다). 내용을 보면 다음처럼 보여진다.

......

c0378f78 T tcp6_proc_exit
c0378f94 t tcp6_seq_show
c0379468 T tcp6_proc_init
c0379484 T ipv6_find_tlv
c037951c T ipv6_fixup_options
c0379590 T ipv6_dup_options
c037960c t ipv6_renew_option
c0379704 T ipv6_renew_options
c0379978 t ipv6_push_exthdr
c03799c8 T ipv6_push_frag_opts
c03799f0 T ipv6_push_nfrag_opts
c0379acc t ipv6_hop_ra
c0379b3c t ip6_parse_tlv
c0379c8c t ipv6_hop_jumbo
c0379e9c T ipv6_parse_hopopts
c0379f74 T ipv6_exthdrs_exit
c0379fb4 t ipv6_rthdr_rcv
c037a1d4 t ipv6_destopt_rcv

.......

앞에 있는 것은 주소값이고 뒤에 있는 것이 심볼명이다.

/proc/loadavg

시스템의 평균 부하를 보여준다.

1.01 0.29 0.10 1/135 794

/proc/meminfo

시스템의 메모리 정보를 보여준다. 주메모리의 크기나 사용량, 가상 메모리, 동적으로 할당된 메모리의 크기 등을 알 수 있다.

MemTotal:       198864 kB
MemFree:        101548 kB
Buffers:            64 kB
Cached:          53608 kB
SwapCached:          0 kB
Active:          47724 kB
Inactive:        34868 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
AnonPages:       28932 kB
Mapped:          24592 kB
Slab:             3116 kB
SReclaimable:      944 kB
SUnreclaim:       2172 kB
PageTables:       2688 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:     99432 kB
Committed_AS:   725592 kB
VmallocTotal:   311296 kB
VmallocUsed:     24784 kB
VmallocChunk:   270332 kB

/proc/modules

현재 커널에 적재된 모듈 정보를 보여준다. 우리가 lsmod 명령으로 확인하는 내용과 같다.

mali 68644 0 - Live 0xbf00e000
hpd 4152 0 - Live 0xbf00b000
audio 5804 0 - Live 0xbf008000 (P)
cec 4420 0 - Live 0xbf005000
hdmidrv 12540 0 - Live 0xbf000000 (P)

/proc/net

네트워크 프로토콜에 대한 정보를 가지고 있다. 이는 디렉토리에 대한 심볼릭 링크이며 self/net와 연결되어 있다.

# ls -l net
lrwxrwxrwx root root 2009-09-03 18:47 net -> self/net

하여간에 net로 이동해서 보면 커널이 지원하는 각종 프로토콜의 현재 상황에 대한 정보를 가진 파일들을 확인할 수 있다.

-r--r--r-- root     root            0 2009-09-03 18:48 packet
-r--r--r-- root     root            0 2009-09-03 18:48 ip6_flowlabel
-r--r--r-- root     root            0 2009-09-03 18:48 rt6_stats
-r--r--r-- root     root            0 2009-09-03 18:48 ipv6_route
-r--r--r-- root     root            0 2009-09-03 18:48 if_inet6
dr-xr-xr-x root     root              2009-09-03 18:48 dev_snmp6
-r--r--r-- root     root            0 2009-09-03 18:48 snmp6
-r--r--r-- root     root            0 2009-09-03 18:48 sockstat6
-r--r--r-- root     root            0 2009-09-03 18:48 udplite6
-r--r--r-- root     root            0 2009-09-03 18:48 raw6
-r--r--r-- root     root            0 2009-09-03 18:48 mcfilter6
-r--r--r-- root     root            0 2009-09-03 18:48 igmp6
-r--r--r-- root     root            0 2009-09-03 18:48 anycast6
-r--r--r-- root     root            0 2009-09-03 18:48 tcp6
-r--r--r-- root     root            0 2009-09-03 18:48 udp6
-r--r--r-- root     root            0 2009-09-03 18:48 unix
-r--r--r-- root     root            0 2009-09-03 18:48 snmp
-r--r--r-- root     root            0 2009-09-03 18:48 netstat
-r--r--r-- root     root            0 2009-09-03 18:48 sockstat
-r--r--r-- root     root            0 2009-09-03 18:48 udp
-r--r--r-- root     root            0 2009-09-03 18:48 tcp
-r--r--r-- root     root            0 2009-09-03 18:48 raw
-r--r--r-- root     root            0 2009-09-03 18:48 udplite
-r--r--r-- root     root            0 2009-09-03 18:48 rt_cache
-r--r--r-- root     root            0 2009-09-03 18:48 route
-r--r--r-- root     root            0 2009-09-03 18:48 arp
-r--r--r-- root     root            0 2009-09-03 18:48 dev_mcast
-r--r--r-- root     root            0 2009-09-03 18:48 wireless
-r--r--r-- root     root            0 2009-09-03 18:48 ptype
-r--r--r-- root     root            0 2009-09-03 18:48 softnet_stat
-r--r--r-- root     root            0 2009-09-03 18:48 dev
-r--r--r-- root     root            0 2009-09-03 18:48 protocols
-r--r--r-- root     root            0 2009-09-03 18:48 netlink
dr-xr-xr-x root     root              2009-09-03 18:48 netfilter
dr-xr-xr-x root     root              2009-09-03 18:48 stat

위의 정보는 크게 ipv6를 위한 정보와 일반 정보로 분류할 수 있다.

ipv6와 관련된 정보를 보면 다음과 같다.

udp6 : UDP 소켓 리스트
tcp6 : TCP 소켓 리스트
raw6 : RAW 디바이스 상태
igmp6 : IP 멀티캐스트 주소
if_inet6 : IPv6 인터페이스 주소 목록
ipv6_route : IPv6를 위한 커널 라우팅 테이블
ipv6_stats : Global IPv6 라우팅 테이블
sockstat6 : IPv6 소켓 상태
snmp6 : IPv6 snmp 데이타

일반 네트웍 정보는 다음과 같다.

arp : arp 테이블 (arp 명령으로 확인할 때 이용된다)
dev : 네트웍 디바이스 상태 (ifconfig 명령에서 사용)
ip_fwchains : 방화벽 chain 룰
ip_fwnames : 방화벽 chain 이름
netstat : 네트웍 통계
raw : raw 디바이스 통계
route : 라우팅 테이블 정보 (route 명령에서 사용)
rpc : rpc 정보 디렉토리
rt_cache : 라우팅 캐쉬
snmp : SNMP 데이타
socket : 소켓 통계
tcp : tcp 소켓
tr_rif : Token Ring RIF 라우팅 테이블
udp : udp 소켓
unix : Unix 도메인 소켓
wireless : Wireless 인터페이스 데이타
igmp : IP 멀티캐스트 주소
psched : Global Packet Scheduler Parameter
netlink : PF_NETLINK 소켓 리스트
ip_mr_vifs : Multicast Virtual Interface 리스트
ip_mr_cache : Multicast Routing Cache 리스트

/proc/self

현재 /proc 디렉토리를 이용하는 프로세스 ID에 실볼릭 링크된 정보를 보여준다고 한다. 정확한 의미는 모르겠지만 ls로 확인해 보면 다음과 같다.

# ls -l self
lrwxrwxrwx root root 2009-09-03 18:39 self -> 816

뒤의 PID는 수행할 때 마다 매번 달라진다. 이 부분에 대해서는 좀 더 확인해 봐야 겠다.

/proc/stat

커널과 시스템의 정보를 보여준다.

cpu 2438 87 1912 86221 0 17 10 0 0
cpu0 2438 87 1912 86221 0 17 10 0 0
intr 183506 0 90685 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 91814 0 1 0 0 108 108 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 46 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 743 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ctxt 145002
btime 1252003168
processes 820
procs_running 3
procs_blocked 0

/proc/sys

커널이 사용중인 커널 변수 정보를 가지고 있는 디렉토리이다. 크게 다음 디렉토리로 다시 구분되어 있다.

# ls -l
dr-xr-xr-x root     root              2009-09-03 18:39 kernel
dr-xr-xr-x root     root              2009-09-03 18:39 vm
dr-xr-xr-x root     root              2009-09-03 18:55 fs
dr-xr-xr-x root     root              2009-09-03 18:55 debug
dr-xr-xr-x root     root              2009-09-03 18:55 dev
dr-xr-xr-x root     root              2009-09-03 18:55 net

각각의 디렉토리로 이동하면 커널이 사용하는 각각의 변수 값이 파일 처럼 존재하는 것을 확인할 수 있다.

/proc/uptime

시스템의 가동시간을 보여준다. 이로부터 가동시간, 사용인원, 평균 시스템 부하등의 정보를 볼 수 있다고 한다(이는 uptime 명령을 사용하는 경우를 말한다). 실제로 보면 2개의 시간 정보가 보여지는데 이것으로 어떻게 저런 내용을 확인할 수 있는지 잘 모르겠다.

1309.05 1258.23

uptime 명령으로 확인하면 다음과 같다.

19:04:36 up 25 min, load average: 0.05, 0.44, 0.45

/proc/version

커널 버젼 정보를 보여준다. 커널 버젼, 작업자, gcc 버젼, 생성 날짜 등의 정보를 확인할 수 있다.

Linux version 2.6.27 (B040017@sys2and-desktop) (gcc version 4.3.1 (GCC) ) #4 Thu Oct 22 22:08:58 KST 2009

/proc/pci

/proc/scsi

시스템에 있는 PCI와 SCSI 디바이스들의 정보를 보여준다. 당연히 현재 사용하는 안드로이드 환경에서 지원하지 않기 때문에 존재하지 않는다. PC에서 확인해 봐도 보이지 않는다.

/proc/번호

번호는 디렉토리이다. 이 번호는 PID(Process ID)를 의미한다. 보통 터미널에서 ps 명령어를 치면 보여지는 내용을 만들 때 이 번호 디렉토리의 내용을 이용한다.

임의의 번호로 이동하면 다음과 같은 구조로 되어 있다.

dr-xr-xr-x app_0    app_0             2009-09-03 19:12 task
dr-x------ root     root              2009-09-03 19:12 fd
dr-x------ root     root              2009-09-03 19:12 fdinfo
dr-xr-xr-x app_0    app_0             2009-09-03 19:12 net
-r-------- root     root            0 2009-09-03 19:12 environ
-r-------- root     root            0 2009-09-03 19:12 auxv
-r--r--r-- root     root            0 2009-09-03 19:12 status
-r-------- root     root            0 2009-09-03 19:12 limits
-rw-r--r-- root     root            0 2009-09-03 19:12 sched
-r--r--r-- root     root            0 2009-09-03 19:08 cmdline
-r--r--r-- root     root            0 2009-09-03 19:08 stat
-r--r--r-- root     root            0 2009-09-03 19:12 statm
-r--r--r-- root     root            0 2009-09-03 19:12 maps
-rw------- root     root            0 2009-09-03 19:12 mem
lrwxrwxrwx root     root              2009-09-03 19:12 cwd -> /
lrwxrwxrwx root     root              2009-09-03 19:12 root -> /
lrwxrwxrwx root     root              2009-09-03 19:12 exe -> /system/bin/app_process
-r--r--r-- root     root            0 2009-09-03 19:12 mounts
-r--r--r-- root     root            0 2009-09-03 19:12 mountinfo
-r-------- root     root            0 2009-09-03 19:12 mountstats
--w------- root     root            0 2009-09-03 19:12 clear_refs
-r--r--r-- root     root            0 2009-09-03 19:12 smaps
-r-------- root     root            0 2009-09-03 19:12 pagemap
-r--r--r-- root     root            0 2009-09-03 19:12 wchan
-r--r--r-- root     root            0 2009-09-03 19:12 schedstat
-r--r--r-- root     root            0 2009-09-03 19:12 oom_score
-rw-r--r-- root     root            0 2009-09-03 19:07 oom_adj
-rw-r--r-- root     root            0 2009-09-03 19:12 coredump_filter

간단히 내용을 정리하면 다음과 같다.

cmdline : 프로세스를 실행한 명령어를 모두 보여준다.
environ : 이 프로세스가 참조하는 환경변수 정보를 갖고 있다.
fd : 프로세스가 참조하는 파일 목록 정보, 파일명이 0 부터 시작되어 링크된 파일을 확인한다.
maps : 현재 프로세스가 사용하고 있는 메모리 구역 정보인데 주로 보면 lib가 로딩된 메모리 위치를 확인할 수 있다.
stat, statm, status : 프로세스의 상태 정보들을 담고 있다. stat는 프로세스의 상태를 statm은 프로세스의 메모리 상태, status는 사람이 보기 편한 형태로 프로세스의 상태를 나타낸다.
mem : 프로세스가 억세스 하는 메모리 (?)
root : 프로세스의 루트 디렉토리 (심볼릭 링크)
cwd : 프로세스의 작업 디렉토리 (심볼릭 링크)
exe : 이 프로세스를 실행한 바이너리 (심볼릭 링크)

DNS (Domain Name Service)

2009-10-20T14:21:15Z

만약 다음과 같이 도메인 이름으로 ping을 하면 당연한 얘기지만 DNS에 접속해서 해당 이름에 대한 IP와 MAC Address를 얻어온다.

이에 대한 응답은

네트워크 디바이스 드라이버 동작 테스트

2009-10-18T21:23:00Z

여러가지 방법이 있겠지만 가장 간단한 방법은 패킷 분석기를 이용하는 것이다.

1. 네트웍크 설정

먼저 여러 장치들이 연결된 곳에서 테스트를 하면 전송되는 패킷이 너무 많으므로 PC와 1:1로 붙인다

이 경우 PC의 IP는 테스트 보드의 Gateway가 되고 테스트 보드의 IP는 PC의 Gateway가 된다.

2. WireShark를 실행 시키고 Capture상태로 놓는다.

3. 테스트 보드의 콘솔에서 Ping을 실행한다.

보통 ARP와 ICMP 패킷이 정상적으로 왔다 가는지를 확인하면 된다.

ICMP (Internet Control Message Protocol) 와 Ping

2009-10-18T12:58:15Z

ICMP(Internet Control Message Protocol)는 IP의 에러 메시지나 제어 메시지를 전송하기 위한 프로토콜이다. 이는 Connection이 없어도 사용되는 프로토콜이며 주로 Ping이 주로 사용한다.

ICMP가 전송되기 위해서는 LLC + IP + ICMP 로 이루어진 패킷을 전송하게 된다.

먼저 LLC를 보면 Type 은 0x0800이 된다 (ARP의 경우는 0x0806)

IP 부분은 잠시 잊고 ICMP 쪽만 보면

Type (1Byte)

Code (1Byte)

Checksum (2Byte)

Data (4Byte : Identifier + Sequence number)

이 후 32Byte의 데이터가 추가되는데 여기서 보면 a~z 까지의 값을 나열한 특별한 의미 없는 데이터이다.

IP DataGram에서 전송될 데이터를 40Byte로 하고 있기 때문에 ICMP를 위한 8Byte외의 32Byte를 채워넣어 둔 것이다.

보통 Ping의 경우는 Code를 0으로 사용하고 이 경우에 Type의 의미는 다음과 같이 정의되어 있다.

8 : Echo Request

0 : Echo Reply

3 : Destination Unreachable

내용을 보면 알겠지만 ICMP 자체는 Control Message가 어떤 종류인지 정도만을 나타낸다.

실제 보내는 주소와 관련된 내용은 MAC 정보는 LLC에 IP 주소 정보는 IP에 존재한다. (당연한 얘기죠)

IP DataGram에서 주의해서 볼 내용은 ICMP를 전송하는 경우이므로 Protocol 을 보면 0x01로 ICMP임을 나타내고 있다. 이 값은 TCP인 경우는 6이고 UDP인 경우는 17이다.

ARP(Address Resolution Protocol)

2009-10-17T16:32:12Z

ARP (Address Resolution Protocol)

IP가 패킷을 라우팅할 떄, 물리적 통신을 당담하는 네트워크 어댑터 카드가 인식할 수 있는 하드웨어 어드레스(즉 MAC Address)가 필요하다. IP는 이 MAC Address를 알아 내야만 통신을 할 수가 있다. IP가 통신을 원하는 호스트의 MAC Address를 요청하면 APR는 ARP Cache를 찾아서 관련 정보가 있는지 찾고 없으면 IP Address를 가지고 MAX Addreess를 찾기 위하여 ARP 요청 프레임을 만들고 이것을 네트워크에 broadcast 한다.

네트워크에 연결된 여러 호스트가 받은 후, IP Address와 일치하는 IP를 가진 호스트가 응답을 하게 되고 나머지는 이를 버린다.

실제 ARP를 보면

위의 내용을 보면 총 60Byte를 캡쳐했는데 실제 ARP와 관련된 것은 42Byte이고 나머지는 0으로 패딩되어 있다.

처음 14Byte는 Ethernet II 정보 즉 Destination MAC(6bye), Source MAC(6byte) 그리고 Type(2bye)이며 Type값이 0x0806으로 ARP임을 나타낸다.

실제 ARP 프로토콜은 28Byte(8+10+10)로

Hardware Type : 2byte

Protocol Type : 2Byte

Hardware Size : 1Byte (보통 항상 6으로 MAC 어드레스의 크기를 나타낸다)

Protocol Size : 1Byte (보통 항상 4로 IP 어드레스의 크기를 나타낸다)

Opcode : 2Byte

Sender MAC + IP : 10Byte

Target MAC + IP : 10Byte

즉 이 내용은 192.168.1.28을 IP로 갖는 쪽에서 192.168.1.6 을 찾고 있는 것이다.

OpCode의 값은 0x0001로 되어 있다. 이는 Request이기 때문이다. 만약 이러한 요청에 대한 응답을 하게 되는 경우라면 OpCode는 0x0002가 되고 그 이후에 보내지는 Sender MAX + IP 와 Target MAC + IP의 값이 모두 채워져서 전송되게 된다.

ARP 패킷을 보내기 전에 ARP Cache를 찾아서 기본에 접속해서 IP에 대한 MAC 어드레스가 있는지 확인한다고 했는데 Windows나 Linux 코두 arp utility를 제공한다. 이를 실행하면 현재 ARP Cache의 내용을 확인할 수 있다.

$arp -a

네트워크 패킷 분석툴

2009-10-17T14:43:57Z

패킷 분석기로 유명한 툴로 Ethereal 이란 것이 있습니다.

Ethereal을 사용하기 위해서는 윈도우에서 프로토콜을 캡쳐하는 WinPcap 드라이버와 Dll이 필요합니다. 관련 홈페이지는 http://www.ethereal.com 과 http://winpcap.polito.it 입니다.

다운받아서 설치하려고 하니 Ethereal이 설치가 잘 안되는 것 같습니다. 확인해보니 최근에는 Ethereal 이란 이름 대신 wireshark란 것으로 이름이 바뀌어서 제공한다고 합니다.(http://www.wireshark.org/ ) 다운 받아서 확인해 보니 WinPcap도 자동으로 설치해 주고 정상적으로 잘 동작합니다.

기본적인 실행 방법은 다음과 같습니다.

첫 실행 화면입니다.

패킷을 캡쳐하기 위해서는 [Capture]-[Interface]를 선택합니다.

현재 컴퓨터에 설치된 Interface를 보여줍니다. 이중 패킷을 캡쳐하려는 장치를 확인 후 [Start] 버튼을 누릅니다. [Option] 버튼을 이용하여 패킷 캡쳐할때 필터링 등을 설정할 수 있습니다.

현재 들어오는 패킷을 분석해서 보여줍니다. 보고 싶은 패킷을 선택하면 자세한 데이터 내용을 확인할 수 있습니다.

패킷 캡쳐를 멈추고 싶으면 다시 [Capture]-[Stop]을 선택합니다.

Ethernet 사용하기

2009-10-17T09:34:22Z

안드로이드는 기본적으로 WIFI를 지원한다. Ethernet을 사용하기 위해서는 아주 많은 작업은 필요없다.

이유는 리눅스가 기본적으로 Ethernet을 지원하기 때문이다.

단 커널 컴파일은 다시 해야 한다.

Make menuconfig 해서 Network support로 들어가서 Networking options의 설정을 확인해야 한다.

기본적으로 WIFI만 지원하는 경우 아래와 같이 설정되어 있을 수도 있다.

Ethernet을 사용하기 위해서는 다음과 같이 수정한다.

Ethernet Device Driver도 설정해 주어야 한다.

사용하려는 Device Driver가 이미 있다는 가정하에서 DM9000을 선택한다. DM9000을 선택할 때 모듈 타입과 커널에 정적으로 결합되도록 선택할 수 있다. 테스트 과정에서는 디바이스 드라이버를 계속 변경할 수도 있으므로 모듈 타입으로 하는 것이 좋다. 또 예전에는 정적으로 결합하도록 디바이스 드라이버를 만들었고 이 경우 관련 디바이스 드라이버를 probe 할 수 있게 코드를 수정해 주어야 한다. 하지만 최근에는 모듈 타입으로 해서 매크로에 의해 probe 하는 것이 더 많이 사용되는 것 같다.

부팅 후에 네트웍 설정을 맞추는 작업이 필요하다.

일단 테스트를 위하여 Ethernet Device Driver는 SD Card에 저장해 둔다.

기본적으로 있는 네트웍 유틸리티는 정상적으로 동작하지 않는 경우도 있는 것 같다. busybox에 있는 것을 사용하는 것이 좋을 것 같으며 작업을 편리하게 하기 위하여 link를 걸어둔다.

$busybox ash

$ln -s system/bin/busybox ifconfig

$ln -s system/bin/busybox route

$ln -s system/bin/busybox arp

디바이스 드라이버 파일을 Load한다.

$insmod dm9000.ko

디바이스 드라이버가 정상적으로 Load 되었는지는 lsmod로 확인이 가능하고 Unload는 rmmod로 한다.

디바이스 드라이버가 정상적으로 Load 되었는지를 확인하는 다른 방법은 ifconfig를 이용하는 것이다.

$./ifconfig -a

위의 명령은 전체 Ethernet 드라이버의 상태를 보겠다는 것이다. 디바이스 드라이버가 Load 되어 있지 않다면 루프백 장치(논리적인 장치)인 lo만 보일 것이다. 만약 정상적으로 Load되었으면 eth0과 lo가 보일 것이다.

eth0이 보이는 지 확인한 후 네트웍 환경을 설정한다. (만약 테스트하는 환경에서 IP가 192.168.21.33이고 Gateway가 192.168.21.254라고 하면)

$./ifconfig eth0 down

$./ifconfig eth0 hw ether 00:12:34:56:78:19

$,/ifconfig eth0 192.168.21.33 up

$./route add default gw 192.168.21.254 eth0

위에서 eth0으로 잡힌 장치의 MAC 어드레스를 00:12:34:56:78:19로 잡아주는 과정이 필요한 경우도 있고 아닌 경우도 있다.

만약 고립된 네트워크에서 혼자 테스트하는 경우라면 MAC 어드레스는 디바이스 드라이버에 Default로 써넣어준 값을 이용할 수도 있다. 그러나 여러 디바이스가 연결된 경우에는 같은 MAC 어드레스를 이용하면 충돌이 나서 정상적인 테스트를 할 수 없다.

이 경우 디바이스 드라이버에서 특별한 ID 에 따라서 MAC 어드레스를 자동으로 변경 가능하는 코드를 넣을 수도 있지만 위와 같이 ifconfig로 수정하는 것도 하나의 방법이다.

위에까지 정상적으로 되었다면 ping을 이용해서 동작 테스트를 할 수 있다.

$ping 192.168.21.254

만약 문제가 있다면 ARP 패킷으로 MAC 어드레스 받아오는 부분부터 문제가 생길 것이다. 정상적으로 ARP 패킷 수신했는지는 arp 명령어로 확인한다.

당연한 얘기지만 Web Browser를 사용하기 위해서는 DNS 설정이 필요하다. WIFI 모듈을 사용하는 경우에 DHCPCD에 의해서 DNS 정보를 얻어올 수 있지만 현재는 테스트하는 과정이므로 강제로 DNS 값을 설정한다.

$setprop net.dns1 192.168.1.36

setprop와 getprop는 다른쪽에서 설명하였지만 안드로이드에서 내부 환경 변수 등을 설정하거나 얻어올 수 있다.

net.dns1 의 값을 설정해주면 이후는 별 문제없이 동작한다.

네트워크 드라이버

2009-10-16T10:58:36Z

리눅스에서 네트워크 드라이버(특히 Ethernet 드라이버)를 사용하기 위해서는 커널 설정에서 다음 세 항목 CONFIG_NET, CONFIG_NETDEVICE. CONFIG_NET_ETHERNET이 선택되어 있어야 한다.

리눅스는 네트워크 드라이버를 char/block 드라이버 다른 별도의 드라이버로 구현한다.

net_device 구조체를 이용하여 네트워크 장치에 필요한 모든 정보를 관리하며 이는 include/linux/netdevice.h에 정의되어 있다.

net_device 구조체는 register_netdev() 함수를 이용하여 등록하고 unregister_netdev()에 의하여 해제된다.

static struct net_device dev;

static int init_module(void)

{

register_netdev(&dev);

}

static void cleanup_module(void)

{

unregister_netdev(&dev);

}

리눅스 커널 버젼 관리

2009-10-13T14:08:49Z

리눅스의 디바이스 드라이버를 만들다 보면 커널 버젼에 따라서 수정할 내용이 발생한다.

이를 위해서 보통 다음과 같이 feature 작업을 하게 된다.

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 4, 28)

...

#endif

실제 커널의 버젼과 KERNEL_VESION 매크로는 kernel\include\linux\vesion.h 에서 관리한다.

#define LINUX_VERSION_CODE 132635
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

커널 버젼이 132635 는 2.6.1B 이다 즉 2.6.17 버젼이다.

네트워크 설정 관련

2009-10-12T20:20:03Z

임베디드 리눅스에서 네트워크 설정 관련한 내용이다.

임베디드 리눅스의 경우 ifconfig 나 route 등의 유틸리티가 기본적으로 없고 busybox에 묶여 있는 경우도 있다.

이를 위해서 다음과 같이 link를 건다. (아래의 예제는 타겟 시스템이 안드로이드인 경우이고 system/bin 디렉토리 안에 유틸리티가 있다)

$ln -s system/bin/busybox ifconfig

$ln -s system/bin/busybox route

이후 ifconfig나 route를 사용할 때는 다음과 같이 사용한다.

$./ifconfig

$./route

insmod로 네트워크 디바이스 드라이버(예로 dm9000.ko)를 올려주는 경우에는 다음과 같이 한다.

$insmod dm9000.ko

ifconfig로 eth0이 잡혀있는지 확인하고 사용할 IP 주소를 설정해 준다.

$./ifconfig -a

$,/ifconfig eth0 down

$./ifconfig eth0 192.168.xxx.xxx up

netmask와 broadcast를 따로 설정해 줄수도 있지만 보통은 IP address만 설정해 주면 되낟.

설정된 정보를 확인하면 다음과 같다.

$ ./ifconfig
eth0      Link encap:Ethernet HWaddr 00:12:34:56:78:00
          inet addr:192.168.xxx.yyy Bcast:192.168.xxx.255 Mask:255.255.255.0
          inet6 addr: fe80::212:34ff:fe56:7800/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:706 (706.0 B)
          Interrupt:7 Base address:0xe30

lo        Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:40 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4480 (4.3 KiB) TX bytes:4480 (4.3 KiB)

RX bytes 와 TX bytes 를 확인하면 현재 리눅스가 받아들인 데이터의 양과 외부로 전송한 데이터의 양을 알 수 있다.

gateway를 설정해 준다. 현재 설정된 gateway 정보를 보려면 다음과 같다.

$./route

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.21.0 * 255.255.255.0 U 0 0 0 eth0

gateway는 다음과 같이 설정한다.

$./route add default gw 192.168.xxx.yyy dev eth0

$./route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.21.0    *               255.255.255.0   U     0      0        0 eth0
default         192.168.21.254 0.0.0.0         UG    0      0        0 eth0

이 외 네트워크 관련하여 사용하는 유틸리티는 netstat이 있다.

이는 설정하고는 관계없고 현재 연결되었거나 연결될 목록을 보여준다.

$netstat

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN

Proto : 현재 사용한 프로토콜

Local Address : 현재 열려 있는 사용자 컴퓨터의 IP(호스트 네임) 과 사용중인 포트

Foreign Address : 현재 접속되어 있는 IP(호스트 네임)과 사용중인 포트

State : 연결 상태

ESTABLISHED : 현재 연결되어 있음

LISTEN : 연결을 위하여 접속을 기다림

TIME_WAIT : 연결 종료되었거나 다음 연결을 위하여 기다리는 상태

SYS_SENT : 접속하기 위해 패킷을 보냈음

DNS 설정 관련해서는 /etc/resolv.conf 파일이 있어야 한다.

사용할 DNS 서버 주소를 설정하는 파일이다.

파일 내용을 보면 다음과 같다.

# Generated by NetworkManager

nameserver 168.126.xxx.xxx

nameserver 168.126.xxx.yyy

resolv.conf가 있으면 dns를 사용하기 위하여 libnss_dns-2.x.so가 필요하며 보통 link로 같이 존재해야 한다.

link가 없으면 다음과 같이 정의해 둔다.

$ln -s libnss_dns-2.x.so libnss_dns.so.2

dmesg

2009-10-11T11:34:17Z

dmesg 명령은 커널 ring 버퍼를 조사하거나 제어하는데 사용된다.

/var/log/dmesg는 부팅하는 동안 커널의 기록을 남겨 놓은 파일이다.

로그를 파일로 저장하고 싶으면

$dmesg > 파일명

메시지 내용을 보여주고 ring 버퍼 내용을 모두 비우고 싶으면

$dmesg -c

만약 로그 중에 특정한 내용을 찾고 싶으면

$dmesg|grep "찾을 내용"

안드로이드 WIFI 설정

2009-10-10T10:17:38Z

안드로이드 WIFI 설정 관련해서 참고할만한 사이트 이다.

http://www.aesop.or.kr/?document_srl=67446&mid=board_android_platform

http://www.aesop.or.kr/?document_srl=55406

http://www.aesop.or.kr/?document_srl=49038&mid=board_android_platform

먼저 커널에서 Network 관련해서 설정해 줘야 한다.

네트웍트 설정 관련해서는 다음과 같다.

설정을 보면 wireless extension을 설정한다. 이와 관련된 내용은 다음을 참조한다.

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

네트웍트 디바이스 드라이버 설정은 다음과 같다.

위의 글을 참고하면 안드로이드 WIFI의 경우 모듈 로딩을 기본으로 하게 되어 있다고 한다.

실제로 ATHEROS 모듈 적용한 경우도 보니 모듈 로딩을 하도록 한 것을 보았다.

위의 글에서는 Marvel 드라이버를 사용하는 경우인데 커널에 Built In 하도록 하고 있다.

이유는 안드로이드의 경우 모듈을 하나만 로딩해야 되는데 모듈을 두개 로딩할 필요가 있어서 편하게 작업한 것으로 보인다.

(SDIO 타입의 WIFI 모듈의 경우 SDIO 디바이스 드라이버 모듈을 로드하고 WIFI 디바이스 드라이버 모듈을 로드해야 한다.)

관련 내용은 hardware/libhardware_legacy/wifi.c 참조

int wifi_load_driver()
{
char driver_status[PROPERTY_VALUE_MAX];

int count = 100; /* wait at most 20 seconds for completion */

    if (check_driver_loaded()) {
        return 0;
    }

if (insmod(DRIVER_MODULE_PATH, DRIVER_MODULE_ARG) < 0)
return -1;

    if (strcmp(FIRMWARE_LOADER,"") == 0) {
        usleep(500000);
        property_set(DRIVER_PROP_NAME, "ok");
    }
    else {
        property_set("ctl.start", FIRMWARE_LOADER);
    }
    sched_yield();
    while (count-- > 0) {
        if (property_get(DRIVER_PROP_NAME, driver_status, NULL)) {
            if (strcmp(driver_status, "ok") == 0)
                return 0;
            else if (strcmp(DRIVER_PROP_NAME, "failed") == 0)
                return -1;
        }
        usleep(200000);
    }
    property_set(DRIVER_PROP_NAME, "timeout");
    return -1;
}

int wifi_unload_driver()
{
int count = 20; /* wait at most 10 seconds for completion */

    if (rmmod(DRIVER_MODULE_NAME) == 0) {
while (count-- > 0) {
     if (!check_driver_loaded())
  break;
         usleep(500000);
}
if (count) {
         return 0;
}
return -1;
    } else
        return -1;
}

실제로 2개의 모듈을 로드해야 된다면 수정 사항은 다음과 같을 것이다.

int wifi_load_driver()
{
char driver_status[PROPERTY_VALUE_MAX];

int count = 100; /* wait at most 20 seconds for completion */

    if (check_driver_loaded()) {
        return 0;
    }

// 새로 추가

if (insmod(DRIVER_MODULE_PATH1, DRIVER_MODULE_ARG) < 0)
return -1;

if (insmod(DRIVER_MODULE_PATH, DRIVER_MODULE_ARG) < 0)
return -1;

......

}

int wifi_unload_driver()
{
int count = 20; /* wait at most 10 seconds for completion */

// 새로 추가

if (rmmod(DRIVER_MODULE_NAME1) != 0)
return -;1

if (rmmod(DRIVER_MODULE_NAME) == 0) {

......

}

구글에서 제공하는 wifi.c 에서 좀더 수정할 내용이 있는데 wifi.c 파일을 보면 초기에 Path, Name 등을 정의해 둔 곳이 있다.

#ifndef WIFI_DRIVER_MODULE_PATH
#define WIFI_DRIVER_MODULE_PATH         "/system/lib/modules/wlan.ko"
#endif
#ifndef WIFI_DRIVER_MODULE_NAME
#define WIFI_DRIVER_MODULE_NAME         "wlan"
#endif
#ifndef WIFI_DRIVER_MODULE_ARG
#define WIFI_DRIVER_MODULE_ARG          ""
#endif
#ifndef WIFI_FIRMWARE_LOADER
#define WIFI_FIRMWARE_LOADER  ""
#endif
#define WIFI_TEST_INTERFACE  "sta"

static const char IFACE_DIR[]           = "/data/system/wpa_supplicant";
static const char DRIVER_MODULE_NAME[] = WIFI_DRIVER_MODULE_NAME;
static const char DRIVER_MODULE_TAG[]   = WIFI_DRIVER_MODULE_NAME " ";
static const char DRIVER_MODULE_PATH[] = WIFI_DRIVER_MODULE_PATH;
static const char DRIVER_MODULE_ARG[]   = WIFI_DRIVER_MODULE_ARG;
static const char FIRMWARE_LOADER[]     = WIFI_FIRMWARE_LOADER;
static const char DRIVER_PROP_NAME[]    = "wlan.driver.status";
static const char SUPPLICANT_NAME[]     = "wpa_supplicant";
static const char SUPP_PROP_NAME[]      = "init.svc.wpa_supplicant";
static const char SUPP_CONFIG_TEMPLATE[]= "/system/etc/wifi/wpa_supplicant.conf";
static const char SUPP_CONFIG_FILE[]    = "/data/misc/wifi/wpa_supplicant.conf";
static const char MODULE_FILE[]         = "/proc/modules";

보통 새로운 WIFI 모듈을 사용한다면 WIFI_DRIVER_MODULE_PATH, WIFI_DRIVER_MODULE_NAME 등은 바꾸어 주어야 한다. 샘플 파일에 WIFI_FIRMWARE_LOADER의 경우 정의되어 있지 않지만 보통 WIFI 모듈은 펌웨어를 다운로드해서 사용하기 떄문에 이 부분도 수정할 필요도 있다. 실제로 드라이버 로드 과정 중에 WIFI_FIRMWARE_LOADER를 체크하여 동작하는 부분이 있다.

int wifi_load_driver()
{
char driver_status[PROPERTY_VALUE_MAX];
int count = 100; /* wait at most 20 seconds for completion */

    if (check_driver_loaded()) {
        return 0;
    }

if (insmod(DRIVER_MODULE_PATH, DRIVER_MODULE_ARG) < 0)
return -1;

    if (strcmp(FIRMWARE_LOADER,"") == 0) {
        usleep(500000);
        property_set(DRIVER_PROP_NAME, "ok");
    }
    else {
        property_set("ctl.start", FIRMWARE_LOADER);
    }

    sched_yield();
    while (count-- > 0) {
        if (property_get(DRIVER_PROP_NAME, driver_status, NULL)) {
            if (strcmp(driver_status, "ok") == 0)
                return 0;
            else if (strcmp(DRIVER_PROP_NAME, "failed") == 0)
                return -1;
        }
        usleep(200000);
    }

......

}

위의 글을 보면 busybox 와 iwconfig를 이용해서 테스트하는 과정을 정리한 내용이 있다.

iwconfig는 ifconfig와 유사하지만 wireless 인터페이스를 위해 만들어 졌다. 보통 wireless 환경을 위한 파라미터 설정(주파수 설정 등 ifconfig에는 없는 내용이 추가)에 사용되며, 설정된 값을 보거나 wireless 상태를 확인하는데도 사용한다. (wireless 상태를 확인하기 위해서 /proc/nex/wiress를 이용)

http://linux.about.com/od/commands/l/blcmdl8_iwconfi.htm

밑에 첨부하는 busybox와 iwconfig를 이용해서 테스트할 수 있습니다.

이 두개의 파일을 안드로이드 rootfs 의 / 에 가져다 놓고
부팅후....

다음과 같은 명령을 내리면 인터넷을 사용할 수 있습니다.
브라우저 이용해서

-------------------------------------------
iwconfig, busybox를 rootfs의 / 에 복사하신 후에
firmware를 rootfs의 system/etc/firmware 디렉토리에 복사해 주시고

부팅 후

// 이 두줄은 한번만
ln -s busybox ./ifconfig
ln -s busybox ./route

// 이렇게 해서
./busybox ash
./ifconfig eth0 up
./iwconfig eth0 essid 'insignal'
./ifconfig eth0 192.168.0.105
./route add default gw 192.168.0.1 eth0
setprop net.dns1 168.126.63.1
--------------------------------------------

이런 방식은 android의 wifi를 쓰는게 아니라 ethernet을 사용하는 것처럼 사용하는 것입니다.

wifi를 쓰려면 wpa_supplicant를 이용해서 처리를 합니다.

iwconfig 사용을 보면 essid를 'insignal'로 설정하고 있다. 이는 네트웍 이름을 설정하는 것이라고 한다.

다음 사이트는 일반적인 PC에서 WIFI를 사용하기 위한 환경 설정을 설명하고 있다. 네트웍과 리눅스에 문외한인 나로서는 좀 도움이 되는 것 같다.

http://innu.pe.kr/tt/tag/iwconfig

안드로이드에서 wifi를 사용할 때는 wpa_supplicant를 이용해서 처리한다고 한다.

이에 대한 정보

http://wiki.kldp.org/wiki.php/GentooX86Handbook_Ko_4-4

위치는

external/wpa_supplicant 이다.

setprop를 이용해서 강제로 DNS 주소를 설정한다. 안드로이드의 경우 /etc/resolv.conf도 없고 libnss_dnx-2.x.so 도 사용하지 않는다.

네트웍 관련된 서비스는 wpa_supplicant와 dhcpcd 정도만 사용한다.

dns 정보의 경우 resolv.conf가 없으므로 setprop로 강제 설정하고 getprop로 설정된 내용을 확인할 수 있는 것 같다. 위에서도 setprop를 사용해서 설정하는 예를 보여주고 있다. 콘솔에서 getprop를 실행하면 현재 설정을 확인할 수 있다.

$getprop

.....
[net.tcp.buffersize.default]: [4096,87380,110208,4096,16384,110208]
[net.tcp.buffersize.wifi]: [4095,87380,110208,4096,16384,110208]
[net.tcp.buffersize.umts]: [4094,87380,110208,4096,16384,110208]
[net.tcp.buffersize.edge]: [4093,26280,35040,4096,16384,35040]
[net.tcp.buffersize.gprs]: [4092,8760,11680,4096,8760,11680]
[init.svc.console]: [running]
[init.svc.servicemanager]: [running]
[init.svc.vold]: [running]
[init.svc.debuggerd]: [running]
[init.svc.ril-daemon]: [running]
[init.svc.zygote]: [running]
[init.svc.media]: [running]
[init.svc.dbus]: [running]
[init.svc.installd]: [running]
[init.svc.keystore]: [running]
[init.svc.adbd]: [running]
[hw.egl.enable]: [1]
[init.svc.bootanim]: [stopped]
[hw.keyboards.65536.devname]: [telechips power key]
[hw.keyboards.0.devname]: [telechips keypad]
[sys.settings_secure_version]: [4]
[dev.bootcomplete]: [1]
[sys.settings_system_version]: [6]
[gsm.sim.operator.numeric]: []
[gsm.sim.operator.alpha]: []
[gsm.sim.operator.iso-country]: []
[gsm.sim.state]: [UNKNOWN]
[gsm.current.phone-type]: [1]
[gsm.operator.alpha]: []
[gsm.operator.numeric]: []
[gsm.operator.iso-country]: []
[gsm.operator.isroaming]: [false]
[EXTERNAL_STORAGE_STATE]: [mounted]

처음에 WIFI 모듈을 연결하지 않은 상태는 위와 같다. WIFI 모듈을 켜고 다시 확인하면 다음과 같은 내용이 추가된다.

wpa_supplicant와 dhcpcd가 동작 상태가 됨을 알 수 있다. 테스트한 경우는 AP에 접속해서 IP나 DNS 정보 등을 가져오지 않았으므로 비정상적인 값이들어가 있다.

......

[EXTERNAL_STORAGE_STATE]: [mounted]

[wlan.driver.status]: [ok]

[init.svc.wpa_supplicant]: [running]
[init.svc.dhcpcd]: [running]
[net.dns1]: [1.1.1.1]
[net.dns2]: [1.1.1.1]
[dhcp.eth0.pid]: [869]
[dhcp.eth0.reason]: [PREINIT]
[net.dnschange]: [1]

Setup에서 다시 WIFI 모듈을 끄고 확인하면 다음과 같다. wpa_supplicant와 dhcpcd 모두 stopped 상태로 된다.

......

[EXTERNAL_STORAGE_STATE]: [mounted]

[wlan.driver.status]: [unloaded]
[init.svc.wpa_supplicant]: [stopped]
[init.svc.dhcpcd]: [stopped]
[net.dns1]: [1.1.1.1]
[net.dns2]: [1.1.1.1]
[dhcp.eth0.pid]: [1569]
[dhcp.eth0.reason]: [FAIL]
[net.dnschange]: [2]
[dhcp.eth0.dns1]: []
[dhcp.eth0.dns2]: []
[dhcp.eth0.dns3]: []
[dhcp.eth0.dns4]: []
[dhcp.eth0.result]: [failed]

위에서는 강제로 net.dns1의 값을 설정해 두고 있다.

그 외 참고 내용으로

위의 글에서 제시하는 방법은

1) external/wpa_supplicant/.config 수정

2) build/target/board/generic/BoardConfig.mk 수정

3) extenal/wpa_supplicant/wpa_supplicant.conf 수정

추가 수정 부분은

1) external/dhcpcd/android.conf

frameworks/base/services/java/com/android/server/WifiWatchdogService.java、
android-1.5r3/frameworks/base/wifi/java/android/net/wifi/WifiStateTracker.java

2) wifi interface 이름 설정은 system/build.prop

3) init.rc 도 수정 필요