상속세 신고 관련 (2014.6.13. 국세청 자료 기준)

* 법정신고기한
  상속개시일이 속하는 달의 말일부터 6월 이내
* 제출대상서류
1. 상속세 과세표준신고 및 자진납부 계산서
2. 상속재산명세서 및 그 평가명세서
3. 피상속인 및 상속인의 가족관계증명서
4. 공과금,장례비,채무사실을 입증하는 서류
5. 상속재산을 감정평가 의뢰한 경우 감정평가 수수료 지급서류
6. 상속재산을 분할한 경우에는 상속재산분할명세서 및 그 평가 명세서
7. 그 밖에 상속세 및 증여세법에 의하여 제출하는 서류 등(예: 가업상속공제신고서 등)

* 세액계산흐름도

항목별 설명은 http://www.nts.go.kr/tax/tax_08.asp?cinfo_key=MINF5520100720170329&menu_a=800&menu_b=200&menu_c=200&flag=08

* 상속 공제





* 다음도 참고
  한국 납세자 연맹의 상속세 관련 부분: http://www.koreatax.org/tax/setech/estate/estate02_point.php3?menuck=open25

 

[Android] “Running Android with low RAM” 의 Kernel Configuration

Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.
 

원문: http://source.android.com/devices/low-ram.html
번역: 양정석<dasomoli@gmailREMOVETHIS.com>(근데 원래 혼자 보려던 거라 이상한 거 많음;;)

커널 설정


직접 회수(Direct reclaim)를 줄이기 위한 커널/ActivityManager 튜닝

직접 회수는 하나의 프로세스 또는 커널이 메모리의 한 페이지를 (직접 혹은 새로운 페이지 안의 폴트로 인해서) 할당하고자 하며, 커널이 모든 사용 가능한 자유 메모리를 사용하고 있을 때 일어납니다. 이것은 커널에게 하나의 페이지를 해제하는 동안 할당을 막도록 요구합니다. 결국 이것은 더티한 File-backed 페이지를 플러싱하기 위한 디스크 I/O나 lowmemorykiller가 프로세스 하나를 죽이기를 기다리는 것을 종종 요구합니다. 이것은 UI 스레드를 포함하는 어떤 스레드에 추가 I/O를 일으킬 수 있습니다.
직접 회수를 피하기 위해서 커널은 kswapd나 백그라운드 회수를 촉발시키는 워터마크를 가집니다. 이것은 페이지들을 해제하도록 시도해서 다음에 그를 할당하는 리얼 타임 스레드가 빨리 수행할 수 있도록 하는 하나의 스레드입니다.
백그라운드 회수를 촉발시키는 디폴트 임계값은 2GB 디바이스에서 2MB, 512MB 디바이스에서 636KB로, 상당히 낮습니다. 그리고 커널은 그저 수 MB의 메모리를 백그라운드 회수 시에 회수할 뿐입니다. 이것은 수 MB 이상을 빨리 할당하는 어떤 프로세스는 빨리 직접 회수를 치게 될 것이라는 것을 의미합니다.
새로운 커널에 튜닝 가능한 지원이 android-3.4 커널 브랜치에 패치 92189d47f66c67e5fd92eafaa287e153197a454f(“add extra free kbytes tunable”)로 추가됩니다. 이 패치를 디바이스의 커널로 체리픽하는 것은 ActivityManager가 커널에게 3개의 풀스크린 32 bpp 버퍼의 메모리를 자유롭게 유지하도록 할 것임을 이야기하는 것을 허용할 것입니다.
이들 임계값은 프레임워크 config.xml을 통해 설정될 수 있습니다.
<!– 커널 내에 (존재한다면) 튜닝 가능한 /proc/sys/vm/extra_free_kbytes를 셋팅하는 디바이스 설정. 높은 값은 커널이 free를 유지하는 메모리의 양을 증가시키고, 할당 시간을 줄이고, lowmemerykiller가 더 빨리 죽이도록 할 것입니다. 낮은 값은 프로세스들에 의해 더 많은 메모리를 사용하도록 하지만 디스크 I/O나 lowmemorykiller 상에서의 대기를 막는 더 많은 할당이 일어날 것입니다. 화면 크기에 기초한 ActivityManager에 의해 선택된 기본 값은 덮어씌움. 0은 커널의 기본 값을 넘는 추가 메모리를 유지하는 것을 막습니다. -1은 기본값을 유지합니다 –>
<integer name=”config_extraFreeKbytesAbsolute”>-1</integer>
<!– 커널 내에 (존재한다면) 튜닝 가능한 /proc/sys/vm/extra_free_kbytes를 조정하는 디바이스 설정. 0은 ActivityManager가 고르는 기본 값을 사용합니다. 양수 값은 커널이 해제를 유지하는 메모리의 양을 증가시키고, 할당 시간을 줄이고, lowmemorykiller 가 더 빨리 죽이도록 할 것입니다. 음수 값은 프로세스들에 의해 사용되는 메모리를 더 많이 허용하지만, 디스크 I/O나 lowmemorykiller 상의 대기를 막는 더 많은 할당이 일어날 것입니다. 화면 크기에 기초한 ActivityManager에 의해 선택된 기본 값은 직접 더해짐. –>
<integer name=”config_extraFreeKbytesAdjust”>0</integer>
LowMemoryKiller 튜닝
ActivityManager는 각 우선 순위 단계 버킷 안에서 프로세스를 실행하는데 필요한 file-backed 페이지(캐시된(cached) 페이지)의 워킹 셋의 그 예상치를 맞추기 위해서 LowMemoryKiller의 임계값을 설정합니다. 디바이스가 워킹 셋을 위한 높은 요구 사항을 갖는다면, 예를 들면, 벤더 UI가 더 많은 메모리를 요구하거나 더 많은 서비스가 추가되었다면, 임계값은 증가될 수 있습니다.
작아지고 있는 캐시 때문에 디스크 스레싱(thrashing)이 일어나기 전에 백그라운드 프로세스들이 죽여지고 있어서, 너무 많은 메모리가 file backed 페이지를 위해 예약되어 지고 있다면 임계값을 줄일 수 있습니다. 
<!– 커널 내의 lowmemorykiller 내의 튜닝 가능한 minfree를 셋팅하는 디바이스 설정. 높은 값은 lowmemorykiller가 더 일찍 켜지고, 파일 캐시 안에 더 많은 메모리를 유지하고, I/O 스레싱을 막도록 할 것이지만, 메모리 내에 더 적은 프로세스가 머물도록 할 것입니다. 낮은 값은 더 많은 프로세스가 메모리 상에 유지되지만, 너무 낮으면 스레싱을 일으킬 것입니다. 화면 크기와 가장 큰 lowmemorykiller 버킷을 위한 전체 메모리에 기초해서 ActivityManager에 의해 선택된 기본값을 덮어쓰고, 더 작은 버킷에 비례해서 크기가 조정됨. -1은 기본값을 유지 —>
<integer name=”config_lowMemoryKillerMinFreeKbytesAbsolute”>-1</integer>
<!– 커널 내의 lowmemorykiller 내의 튜닝 가능한 minfree를 조정하는 디바이스 설정. 높은 값은 lowmemorykiller가 더 일찍 켜지고, 파일 캐시 안에 더 많은 메모리를 유지하고, I/O 스레싱을 막도록 할 것이지만, 메모리 내에 더 적은 프로세스가 머물도록 할 것입니다. 낮은 값은 더 많은 프로세스가 메모리 상에 유지되지만, 너무 낮으면 스레싱을 일으킬 것입니다. 화면 크기와 가장 큰 lowmemorykiller 버킷을 위한 전체 메모리에 기초해서 ActivityManager에 의해 선택된 기본값에 직접 더해지고, 더 작은 버킷에 비례해서 크기가 조정됨. 0은 기본값을 유지 —>
<integer name=”config_lowMemoryKillerMinFreeKbytesAdjust”>0</integer>

Framework의 설정 참고 소스 코드: frameworks/base/services/java/com/android/server/am/ProcessList.java

[Linux:Kernel] 왜 “volatile” 타입 클래스가 쓰이지 않는 것이 좋을까

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).
Documentation/volatile-considered-harmful.txt
번역: 양정석<dasomoli@gmailREMOVETHIS.com>
왜 “volatile” 타입 클래스가 쓰이지 않는 것이 좋은가
—————————————————
C 프로그래머들은 종종 volatile을 그 변수가 현재 스레드의 실행 밖에서 바뀔 수
있다는 의미로 사용합니다; 그 결과, 그들은 가끔 커널 코드 안에서 공유 자료
구조들을 사용할 때 이를 사용하고자 합니다. 다른 말로 하면, 그들은 간단한
atomic 변수의 일종처럼, 그게 아닌데도, volatile 형식을 다루는 것으로 알고
있습니다. volatile 커널 코드의 용도는 거의 절대 맞지 않습니다; 이 문서는 그
이유를 설명합니다.
volatile에 대한 이해를 위한 핵심은 그 목적이 거의 아무도 절대 진정으로 원하지
않는 최적화를 막기 위해서라는 것입니다. 커널 안에서, 누군가는 공유되는
자료 구조를 매우 다른 태스크의 원치 않는 동시 접근으로부터 보호해야 합니다.
원치 않는 동시성에 대한 보호 처리는 또한 거의 모든 최적화에 관련된 문제를 더
효율적인 방법으로 피할 것입니다.
volatile처럼, 자료로 안전하게 동시 접근을 하는 커널 기본 요소(스핀락(spinlock),
뮤텍스(mutex), 메모리 장벽(memory barrier), 기타 등등)는 원치 않는 최적화를
막도록 설계되었습니다. 그들이 적절히 사용된다면, 그들은 volatile을 사용할
필요가 없을 것입니다. volatile이 여전히 필요하다면, 거기에는 거의 확실히 코드
어딘가에 버그가 있습니다. 적절히 작성된 커널 코드 안에서 volatile은 오직
느리게만 만들 것입니다.
일반적인 커널 코드 블록을 생각해 봅시다:
    spin_lock(&the_lock);
    do_something_on(&shared_data);
    do_something_else_with(&shared_data);
    spin_unlock(&the_lock);
모든 코드가 락킹(locking) 규칙을 따른다면, shared_data의 값은 the_lock이 잡힌
동안, 예기치 않게 바뀔 수 없습니다. 그 자료를 가지고 놀고 싶어 할 어떤 다른
코드는 락 상에서 대기할 것입니다. 스핀락 기본 요소는 자료 접근이 그들을
가로지르는 최적화가 되지 않을 것임을 의미하는 메모리 장벽처럼 – 그들은
명시적으로 그렇게 하도록 작성되었습니다 – 동작합니다. 그래서 컴파일러는 그것이
shared_data 안에 있을 것을 안다고 생각할 수도 있지만. spin_lock() 호출이 메모리
장벽처럼 동작한 이후에는, 컴파일러가 알고 있는 어떠한 것도 잊어버리도록 강제할
것입니다. 거기에는 그 자료로의 접근에 대한 최적화 문제는 없을 것입니다.
shared_data가 volatile로 선언되었어도, 락킹은 여전히 필요할 것입니다.
그러나 컴파일러 역시, 우리가 다른 누구도 그것으로 무언가 할 수 없음을 알 때,
크리티컬 섹션 _안에서는_ shared_data로의 접근에 대한 최적화가 막혔으면 할
것입니다. 락이 잡힌 동안, shared_data는 volatile이 아닙니다. 공유된 자료로
뭔가 할 때, 적절한 락킹은 – 잠재적으로 해로운 – volatile을 불필요하게 만들 것
입니다.
volatile 저장 클래스는 근본적으로 메모리-매핑된(memory-mapped) I/O 레지스터들을
위해 의미가 있습니다. 커널 안에서 레지스터 접근 역시 락으로 보호돼야 합니다만,
누군가는 또한 컴파일러가 크리티컬 섹션 안에서 레지스터 접근을 “최적화하는 것”을
원하지 않습니다. 그러나 커널 안에서, I/O 메모리 접근은 언제나
접근자(accessor) 함수를 통해 이루어집니다; I/O 메모리에 포인터를 통해 직접
접근하는 것은 얼굴이 찡그려지고, 모든 아키텍처에서 작동하지 않습니다.
이들 접근자는 원치 않는 최적화를 막도록 작성되었습니다. 그래서, 역시,
volatile은 불필요합니다.
누군가가 volatile을 사용하고자 하는 또 다른 상황은 프로세서가 한 변수의 값을
위해 바쁜-기다림(busy-waiting)을 할 때입니다. 바쁜 기다림을 수행하는 옳은
방법은:
    while (my_variable != what_i_want)
        cpu_relax();
cpu_relax() 호출은 CPU 전력 소비를 낮출 수 있고, 하이퍼 스레드 된 다른
프로세서에 양보할 수 있습니다; 또한 컴파일러 장벽처럼 서비스하는 일이
일어납니다. 그래서, 역시, volatile은 불필요합니다. 물론, 바쁜 기다림은
일반적으로 시작하는 반사회적 행동입니다.
volatile이 커널 안에서 이해되는 적은 수의 드문 상황들이 여전히 있습니다:
  – 직접 I/O 메모리 접근이 동작하는 아키텍처에서는 위에서 설명된 접근자
    함수들이 volatile을 사용할 수 있습니다. 기본적으로, 각 접근자 호출은
    그 자체로 작은 크리티컬 섹션이 되고, 접근이 프로그래머가 의도한 대로
    일어남을 보장합니다.
  – 메모리를 변경하는, 그렇지만 다른 보이는 부수 효과(side effect)나, GCC에 의해
    제거되는 위험 없는 인라인 어셈블리 코드. volatile 키워드를 asm 문장에
    추가하는 것은 이 제거를 막을 것입니다.
  – jiffies 변수는 그것이 참조되는 순간마다 다른 값을 가지지만, 어떤 특별한
    락킹도 없이 읽힐 수 있어서 특별합니다. 그래서 jiffies는 volatile일 수
    있지만, 이 타입의 다른 변수들의 추가는 강하게 얼굴이 찌푸려집니다.
    jiffies는 이런 점에서 (리누스의 말로) “멍청한 유산” 이슈로 생각됩니다; 이를
    고치는 것은 그 가치보다 더 많은 문제를 일으킬 수 있습니다.
  – 가끔 합법적으로 volatile이 될 수 있는 I/O 장치에 의해 수정될 수 있는
    일관적인(coherent) 메모리 안의 자료 구조로의 포인터. 네트워크 어댑터가 어떤
    기술자(descriptor)가 처리되었는지를 나타내기 위해 포인터를 수정하는 데서,
    그 어댑터에 의해 사용되는 링 버퍼가 이런 종류 상황의 한 예제입니다.
코드 대부분에서, volatile의 적용을 위한 위의 타당한 이유가 없습니다. 그 결과,
volatile의 사용은 버그처럼 보이고, 코드에 추가적인 정밀 조사를 가져오도록 할
가능성이 큽니다. volatile을 사용하고자 하는 개발자들은 발걸음을 돌리고 그들이
정말로 하고자 하는 바에 대해서 생각해 봐야 할 것입니다.
volatile 변수들의 제거 패치는 – 그들이 동시성 이슈들을 적절히 생각했음을
보여주는 타당한 이유로 다가오는 만큼 – 일반적으로 환영받습니다.
참고
—-
[1] http://lwn.net/Articles/233481/
[2] http://lwn.net/Articles/233482/
언급해야 할 이름
—————-
원래의 자극과 연구는 Randy Dunlap에 의해
작성은 Jonathan Corbet에 의해
의견을 통한 개선은 Satyam Sharma, Johannes Stezenbach, Jesper
Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan
Richter로부터.
한국어 번역은 양정석이.

[Linux:Kernel] 동적 디버그 사용법(dynamic debug howto.txt)

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/dynamic-debug-howto.txt

번역: 양정석<dasomoli@gmailREMOVETHIS.com>

소개

====

이 문서는 어떻게 동적 디버그 (Dynamic Debug:dyndbg) 기능을 사용하는지 설명합니다.

동적 디버그는 여러분이 추가적인 커널 정보를 얻을 수 있도록 동적으로 커널 코드를 켜고/끌

수 있도록 설계되었습니다. 현재는 CONFIG_DYNAMIC_DEBUG가 설정되어 있다면, 모든

pr_debug()/dev_dbg() 그리고 print_hex_dump_debug()/

print_hex_dump_bytes() 호출은 호출하는 지점마다(per-callsite) 동적으로 켜질

수 있습니다.

CONFIG_DYNAMIC_DEBUG가 설정되어 있지 않으면, print_hex_dump_debug()는

그저 print_hex_dump(KERN_DEBUG)의 축약입니다.

print_hex_dump_debug()/print_hex_dump_bytes()에서 만약 그것이 변하지 않는

문자열이라면 형식 문자열(format string)은 그 ‘prrefix_str’ 인자입니다;

또는 ‘prefix_str’ 이 빌드 시 동적인 경우라면 “hexdump”.

동적 디버그는 더 유용한 기능들도 가집니다:

 * 0이나 1의 조합으로 매칭해서 디버깅 문장을 끄고 켤 수 있도록 하는 간단한 쿼리 언어:

   – 소스 파일 이름

   – 함수 이름

   – (행 번호의 범위를 포함하는) 행 번호

   – 모듈 이름

   – 형식 문자열

 * debugfs 제어 파일 제공: 여러분을 안내하는데 도움이 되도록, 알려진 디버그 문장들의

   완전한 목록을 보이도록 읽혀질 수 있는 <debugfs>/dynamic_debug/control.

동적 디버그 동작 제어하기

=========================

pr_debug()/dev_dbg()의 동작은 이 기능의 용도에 따라 ‘debugfs’ 파일 시스템 내의

제어 파일에 쓰는 것을 통해 제어됩니다. 이어서, 우리는 제어 파일을 알아봅니다:

<debugfs>/dynamic_debug/contorl. 예를 들어, 여러분이 소스 파일 ‘svcsock.c’의

1603번째 행에서 출력을 켜기를 원한다면, 간단히 이렇게 하세요:

nullarbor:~ # echo ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

여러분이 문법을 틀린다면, 쓰기가 실패할 것입니다:

nullarbor:~ # echo ‘file svcsock.c wtf 1 +p’ >
<debugfs>/dynamic_debug/control

-bash: echo: write error: Invalid argument

동적 디버그 동작 보기

=====================

여러분은 다음을 통해 현재 설정된 모든 디버그 문장의 동작을 볼 수 있습니다:

nullarbor:~ # cat <debugfs>/dynamic_debug/control

# filename:lineno [module]function flags format

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ “SVCRDMA Module Removed, deregister RPC RDMA transport\012”

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ “\011max_inline       : %d\012”

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ “\011sq_depth         : %d\012”

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ “\011max_requests     : %d\012”


여러분은 또한 이 데이터에 표준 유닉스 텍스트 조작 필터를 적용할 수 있습니다. 예를 들면,

nullarbor:~ # grep -i rdma <debugfs>/dynamic_debug/control  | wc -l

62

nullarbor:~ # grep -i tcp <debugfs>/dynamic_debug/control | wc -l

42

세번째 열은 현재 각 디버그 문장을 호출하는 곳마다의 켜짐 플래그(이 플래그의 정의는

아래를 보세요)를 보여줍니다. 아무 플래그도 설정되지 않은, 기본 값은 “=_” 입니다.

그래서 여러분은 모든 디버그 문장 호출처를 기본값이 아닌 플래그로 볼 수 있습니다:

nullarbor:~ # awk ‘$3 != “=_”‘ <debugfs>/dynamic_debug/control

# filename:lineno [module]function flags format

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p “svc_process: st_sendto returned %d\012”

명령 언어 레퍼런스

==================

어휘적인 수준에서, 하나의 명령은 스페이스나 탭으로 나뉘어진 단어 순서로 구성됩니다.

그래서 이들은 모두 동등합니다:

nullarbor:~ # echo -c ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

nullarbor:~ # echo -c ‘  file   svcsock.c     line  1603 +p  ‘ >
<debugfs>/dynamic_debug/control

nullarbor:~ # echo -n ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

명령 제출은 write() 시스템 호출로 경계지어집니다. 여러 명령은 ‘;’ 나 ‘\n’ 으로

나뉘어져서 함께 쓰여질 수 있습니다.

  ~# echo “func pnpacpi_get_resources +p; func pnp_assign_mem +p” \

     > <debugfs>/dynamic_debug/control

여러분의 쿼리 집합이 크다면, 역시 이를 일괄적으로 수행할 수 있습니다:

  ~# cat query-batch-file > <debugfs>/dynamic_debug/control

다른 방법은 와일드카드를 사용하는 것입니다. 매치 규칙은 ‘*’ (0개나 그 이상의 문자들과

매치)과 ‘?’ (정확히 하나의 문자와 매치)를 지원합니다. 예를 들면, 여러분은 모든 usb

드라이버들을 매치시킬 수 있습니다:

  ~# echo “file drivers/usb/* +p” > <debugfs>/dynamic_debug/control

문법적인 수준에서, 매치 명세(match-spec)들, 그 뒤에 플래그 변경 명세(flags-spec)

의 순서로 구성됩니다.

command ::= match-spec* flags-spec

매치 명세들은 플래그 변경 명세를 어디에 적용해야 하는지를 위해 알려진 pr_debug()

호출처의 부분 집합을 고르는데 사용됩니다. 각 짝들 사이에 암묵적인 AND로 하나의 쿼리처럼

그들을 생각하세요. 매치 명세의 빈 목록은 모든 디버그 문장 호출처를 선택함을 알아두세요.

매치 명세는 비교되는 호출처의 속성을 제어하는 하나의 키워드, 그리고 비교될 하나의 값으로

구성됩니다. 가능한 키워드들은:

match-spec ::= ‘func’ string |
      ‘file’ string |
      ‘module’ string |
      ‘format’ string |
      ‘line’ line-range

line-range ::= lineno |
      ‘-‘lineno |
      lineno’-‘ |
      lineno’-‘lineno

// 알림: line-range 스페이스를 포함할 수 없습니다. 예를 들면,

// “1-30″은 유효한 범위이지만, “1 – 30″은 아닙니다.

lineno ::= unsigned-int

각 키워드의 뜻은:

func

    주어진 문자열은 각 호출처의 함수 이름과 비교됩니다 예를 들면:

    func svc_tcp_accept

file

    주어진 문자열은 전체 경로 이름이나 소스 루트의(src-root) 상대 경로 이름, 또는 각

    호출처의 소스 파일의 경로를 제외한 이름(basename)과 비교됩니다. 예를 들면:

    file svcsock.c

    file kernel/freezer.c

    file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c

module

    주어진 문자열은 각 호출처의 모듈 이름과 비교됩니다. 모듈 이름은 “lsmod” 에서 보여지는

    문자열입니다. 즉, 디렉토리나 .ko 접미사가 없고, ‘-‘는 ‘_’로 변경됩니다. 예를 들면:

    module sunrpc

    module nfsd

format

    주어진 문자열은 동적 디버그 형식 문자열 내에서 검색됩니다. 그 문자열은 전체 형식과

    매치될 필요는 없고 오직 일부만 매치되면 된다는 것을 알아두세요. 공백 문자들과 다른

    특수 문자들은 C의 8진수 문자 이스케이프 \ooo 표현을 사용해서 쓰여질 수 있습니다.

    예를 들면, 스페이스 문자는 \040 입니다. 다른 방식으로, 문자열을 쌍따옴표 문자(“) 나

    따옴표(‘)로 둘러쌀 수 있습니다.

    예제:

    format svcrdma:
   // NFS/RDMA 서버 pr_debug 들에서 많음

    format readahead
   // readahead 캐시 안의 pr_debug 들

    format nfsd:\040SETATTR // 공백 문자로 형식을 매치하는 한가지 방법

    format “nfsd: SETATTR”  // 공백 문자로 형식을 매치하는 더 깔끔한 방법

    format ‘nfsd: SETATTR’  // 공백 문자로 형식을 매치하는 또 다른 방법

line

    주어진 행 번호 또는 행 번호의 범위는 각 pr_debug() 호출처의 행 번호와 비교됩니다.

    하나의 행 번호는 호출처 행 번호와 정확히 매치됩니다. 행 번호의 범위는 처음과 마지막의

    행 번호 안의 호출처와 매치됩니다. 첫번째 수가 없는 것은 파일의 첫번째 줄을 의미하고,

    행 번호가 없는 것은 파일의 마지막 줄을 의미합니다. 예를 들면: 

    line 1603
   // 정확히 1603번 줄

    line 1600-1605  // 1600번에서 1605번 줄까지의 여섯 줄

    line -1605
   // 1번 줄에서 1605번 줄까지의 1605 줄

    line 1600-
   // 1600번 줄에서 파일의 끝까지의 모든 줄

플래그 명세는 하나 또는 그 이상의 플래그 성질이 따르는 하나의 변경 동작으로 구성됩니다.

변경 동작은 하나의 성질입니다:

  –    주어진 플래그 제거

  +    주어진 플래그 추가

  =    주어진 플래그로 플래그를 설정

플래그들은 다음과 같습니다:

  p    pr_debug() 호출처 켜기

  f    출력된 메시지 안에 함수 이름을 포함

  l    출력된 메시지 안에 행 번호를 포함

  m    출력된 메시지 안에 모듈 이름을 포함

  t    인터럽트 컨텍스트에서 생성되지 않은 메시지 안에 스레드 ID 포함.

  _    플래그가 설정되지 않음. (또는 입력 상의 다른 것들로 설정)

print_hex_dump_debug()와 print_hex_dump_bytes()에서는, 오직 ‘p’ 플래그가

다른 플래그들이 무시되는 것을 의미합니다.

보여줄 때, 플래그들은 ‘=’이 앞에 옵니다(연상 기호: 무슨 플래그가 현재 동일한지).

Note the regexp ^[-+=][flmpt_]+$ matches a flags specification.

To clear all flags at once, use “=_” or “-flmpt”.

정규표현 ^[-+=][flmpt_]+$ 는 플래그 명세와 매치함을 알아두세요.

모든 플래그를 없애기 위해서, “=_” 나 “-flmpt”를 사용하세요.

부트 프로세스 동안의 디버그 메시지

==================================

부트 프로세스 동안의 코어 코드와 빌트인 모듈 디버그 메시지를 활성화 하기 위해서, 유저 공간과

debugfs 가 존재하기 전에도, dyndbg=”QUERY”, module.dyndbg=”QUERY”, 또는

ddebug_query=”QUERY”(ddebug_query는 dyndbg에 의해 구식이 되었고, 더 이상 사용하지

않습니다)를 사용할 수 있습니다. QUERY는 위에 설명된 문법을 따르지만, 1023 문자를 넘을 수

없습니다. 여러분의 부트로더는 제한으로 더 적은 수를 쓰고 있을 수 있습니다.

이들 dyndbg 파라미터들은 ddebug 테이블이 처리된 후에, arch_initcall 의 일부로

바로 처리됩니다. 그래서 여러분은 이 부트 파라미터를 통해 이 arch_initcall 이후에

모든 코드 안의 디버그 메시지를 켤 수 있습니다.

예를 들면, x86 시스템 상에서 ACPI 활성화는 subsys_initcall 이고,

   dyndbg=”file ec.c +p”

는 여러분의 머신(일반적으로 랩탑)이 임베디드 컨트롤러를 가진다면, ACPI 셋업동안 초기 임베디드

컨트롤러 트랜잭션을 보여줄 것입니다.

PCI (또는 다른 장치들의) 초기화는 또한 디버깅 목적의 이 부트 파라미터 사용의 유력한

후보들입니다.

foo 모듈이 빌트-인이 아니라면, foo.dyndbg 는 여전히 부트 타임에 아무 효과 없이 처리될

것입니다만, 모듈이 이후에 로딩될 때 처리될 것입니다. dyndbg_query= 과 순수한 dyndbg= 은

부트 시에만 처리됩니다.

모듈 초기화 시점의 디버그 메시지

================================

“modprobe foo”가 호출될 때, modprobe는 foo.params를 위해 /proc/cmdline을 스캔하고,

“foo.”을 벗겨서 제거하고, 이를 modprobe args 나 /etc/modprob.d/*.conf 파일 안에

주어진 파라미터들과 함께 다음 순서로 커널에게 넘긴다:

1. # /etc/modprobe.d/*.conf를 통해 주어진 파라미터들

   options foo dyndbg=+pt

   options foo dyndbg # +p로 기본

2. # boot args에서 주어진 foo.dyndbg, “foo.” 는 벗겨져서 제거되어 전달됨

   foo.dyndbg=” func bar +p; func buz +mp”

3. # modprobe로의 args

   modprobe foo dyndbg==pmf # 이전 설정을 덮어 씀

이들 dyndbg 쿼리들은 가장 마지막에 말한 것이 마지막에 적용되도록, 순서대로 적용됩니다.

이것은 boot args가 /etc/modprobe.d(정확하게는 1이 시스템 전체, 2는 커널이나 부트에

의존적임)로부터 이들을 수정하거나 덮어 쓰도록, 그리고 modeprbe args 가 둘 다를 덮어쓰도록

합니다.

foo.dyndbg=”QUERY” 형식 안에서, 쿼리는 반드시 “foo 모듈”을 제외해야 합니다.

“foo”는 param-name 으로부터 추출되고, “QUERY” 내의 각 쿼리에 적용되고, 오직

각 타입의 1 match-spec만 적용됩니다.

dyndbg 옵션은 “가짜” 모듈 파라미터입니다. 이는 다음을 의미합니다:

– 모듈들은 그를 명시적으로 정의할 필요가 없습니다.

– 모든 모듈은 그들이 pr_debug를 사용하든 말든, 아무 말 없이 이를 얻을 수 있습니다.

– 그것은 /sys/module/$module/parameters 안에 나타나지 않습니다. 이를 보기 위해서,

  제어 파일을 grep 하거나, /proc/cmdline 을 검사하세요.
CONFIG_DYNAMIC_DEBUG 커널에서는 디버그 메시지가 더이상 필요하지 않다면, 부트-타임에
주어진 (또는 컴파일 동안 -DDEBUG 플래그에 의해 켜진) 어떠한 셋팅도 이후에 sysfs
인터페이스를 통해 끌 수 있습니다.

   echo “module module_name -p” > <debugfs>/dynamic_debug/control

예제

====

// svcsock.c 파일의 1603번째 줄의 메시지를 켜기

nullarbor:~ # echo -n ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

// svcsock.c 파일 안의 모든 메시지 켜기

nullarbor:~ # echo -n ‘file svcsock.c +p’ >
<debugfs>/dynamic_debug/control

// NFS 서버 모듈의 모든 메시지 켜기

nullarbor:~ # echo -n ‘module nfsd +p’ >
<debugfs>/dynamic_debug/control

// svc_process() 함수 안의 모든 12 메시지를 켜기

nullarbor:~ # echo -n ‘func svc_process +p’ >
<debugfs>/dynamic_debug/control

// svc_process() 함수 안의 모든 12 메시지를 끄기

nullarbor:~ # echo -n ‘func svc_process -p’ >
<debugfs>/dynamic_debug/control

// NFS가 호출하는 READ, READLINK, READDIR 그리고, READDIR+를 위한 메시지 켜기

nullarbor:~ # echo -n ‘format “nfsd: READ” +p’ >
<debugfs>/dynamic_debug/control

// “usb” 문자열을 포함하는 경로의 메시지 켜기

nullarbor:~ # echo -n ‘*usb* +p’ > <debugfs>/dynamic_debug/control

// 모든 메시지 켜기

nullarbor:~ # echo -n ‘+p’ > <debugfs>/dynamic_debug/control

// 모든 켜진 메시지에 모듈과 함수 추가

nullarbor:~ # echo -n ‘+mf’ > <debugfs>/dynamic_debug/control

// boot-args 예제, 가독성을 위해 줄바꿈과 주석을 넣음

Kernel command line: …

  // dyndbg=값 처리 안에서 어떻게 되어가고 있는지 보기

  dynamic_debug.verbose=1

  // 2 빌트인 안의 pr_debug 켜기, #cmt 는 제거됨

  dyndbg=”module params +p #cmt ; module sys +p”

  // 나중에 로딩되는 모듈 안의 2 함수 안의 pr_debug를 켜기

  pc87360.dyndbg=”func pc87360_init_device +p; func pc87360_find +p”

[Linux:Kernel] 커널 메모리 누수 검출기

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/kmemleak.txt

번역: 양정석(dasomoli@gmailREMOVETHIS.com)

커널 메모리 누수 검출기
=======================

소개
—-

Kmemleak은 주인없는 객체들을 해제하지는 않고 그저 /sys/kernel/debug/kmemleak을
통해 보고하는 차이가 있는 가비지 컬렉터 추적
(http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors)
과 비슷한 방법으로, 가능한 커널 메모리 누수를 검출하는 방법을 제공합니다. 유저-공간의
애플리케이션에서 메모리 누수를 검출하는 데 Valgrind 도구(memcheck –leak-check)가
유사한 방법을 사용합니다.

지원되는 아키텍처를 위해 lib/Kconfig.debug 안의 DEBUG_KMEMLEAK 의존성을 체크하세요.

사용법
——

“Kernel hacking” 안의 CONFIG_DEBUG_KMEMLEAK이 켜져야 합니다. 한 커널 스레드가
메모리를 (기본값으로) 매 10분마다 스캔하고, 찾은 새로운 참조되지 않는 객체들의
수를 출력합니다. 모든 가능한 메모리 누수의 자세할 사항을 보기 위해서는:

  # mount -t debugfs nodev /sys/kernel/debug/
  # cat /sys/kernel/debug/kmemleak

중간에 메모리 스캔을 작동시키려면:

  # echo scan > /sys/kernel/debug/kmemleak

모든 현재의 가능한 메모리 누수의 목록을 지우려면:

  # echo clear > /sys/kernel/debug/kmemleak

그려면 새로운 누수는 /sys/kernel/debug/kmemleak을 다시 읽음으로써 나올 것입니다.

주인없는 객체들은 그들이 할당되었던 순서로 나열되고, 목록의 맨 앞의 한 객체는
주인없는 것으로 보고되는 다른 이어지는 객체들의 원인이 될 것입니다.

메모리 스캐닝 파라미터들은 런타임에 /sys/kernel/debug/kmemleak 파일에 씀으로써
바뀔 수 있습니다. 다음 파라미터들이 지원됩니다:

  off           – kmemleak 끄기 (되돌릴 수 없음)
  stack=on      – 태스크 스택 스캐닝 켜기 (기본값)
  stack=off     – 태스크 스택 스캐닝 끄기
  scan=on       – 자동 메모리 스캐닝 스레드 시작하기 (기본값)
  scan=off      – 자동 메모리 스캐닝 스레드 멈추기
  scan=<secs>   – 자동 메모리 스캐닝 주기를 초로 설정
                  (기본 600, 0은 자동 스캐닝 멈춤)
  scan          – 한 번의 메모리 스캔 작동
  clear         – 현재 메모리 누수 혐의자들의 목록 지우기, 모든 현재 보고된
                  참조되지 않는 객체를 회색으로 표시함으로써 끝
  dump=<addr>   – <주소>에서 찾아진 객체에 대한 정보를 덤프

Kmemleak은 또한 부팅 시간에 “kmemleak=off”를 커널 커맨드 라인에 전달함으로써
꺼질 수도 있습니다.

kmemleak이 초기화되기 전에 메모리는 할당되거나 해제될 것이고, 이들 동작은 초기
로그 버퍼 안에 저장될 것입니다.이 버퍼의 크기는
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE 옵션을 통해 설정됩니다.

기본 알고리즘
————-

kmalloc, vmalloc, kmem_cache_alloc과 그 친구들을 통한 메모리 할당은 추적되고,
그 포인터들은, 크기나 스택 추적같은 추가 정보와 함께 prio 검색 트리 안에
저장됩니다. 그에 맞는 해제 함수 호출들은 기록되고 그 포인터들은 kmemleak 자료
구조로부터 제거됩니다.

메모리의 할당된 블록이 (저장된 레지스터들을 포함하는) 메모리 스캐닝을 통해
그 시작 주소나 블록 안의 어떤 위치로의 어떤 포인터도 찾을 수 없다면, 주인없는
것으로 여겨집니다. 이것은 커널이 할당된 블록의 주소를 해제하는 함수로 넘길 수
있는 방법이 없을 것이고, 그래서 그 블록이 메모리 누수라고 여겨진다는 것을
의미합니다.


스캐닝 알고리즘 단계:

  1. 모든 객체를 하얗게 표시 (남은 하얀 객체들은 나중에 주인없는 것으로 여겨질
     것 입니다.)
  2. 데이터 섹션과 스택들의 메모리 시작을 스캔, prio 검색 트리 안에 저장된 주소들에
     대조되는 값을 검사. 하얀 객체로의 포인터가 있다면, 그 객체는 회색 목록에
     추가합니다.
  3. 회색 집합이 끝날 때까지 매칭되는 주소들을 위해 회색 객체들을 스캔(어떤
     하얀 객체들은 회색이 되고, 회색 목록의 끝에 추가됩니다)
  4. 남아있는 하얀 객체들은 주인없는 것으로 여겨지고, /sys/kernel/debug/kmemleak
     을 통해 보고됩니다.

어떤 할당된 메모리 블록들은 커널의 내부 자료 구조 안에 저장된 포인터들을 가지고,
그들은 주인없는 것으로 검출될 수 없습니다. 이를 피하기 위해서, kmemleak은
또한, 찾아질 필요가 있는 블록 주소 범위 내의 주소를 가리키는 값의 수를 저장할
수 있어서 그 블록은 누수로 여겨지지 않습니다. 한 예로 __vmalloc()이 있습니다.

kmemleak으로 특정 섹션 테스트하기
———————————

초기 부팅 상에서 여러분의 /sys/kernel/debug/kmemleak 출력 페이지는 좀
많을 것입니다. 이것은 또한 여러분이 개발을 할 때 매우 버그가 많은 코드를
가진다면 있을 수 있습니다. 이런 상황에서 일하기 위해서
/sys/kernel/debug/kmemleak 출력으로부터 모든 보고된 참조되지 않는 객체를
지우기 위해서 여러분은 ‘clear’ 명령을 사용할 수 있습니다. ‘clear’ 후의
‘scan’을 통해, 여러분은 새로운 참조되지 않는 객체들을 찾을 수 있습니다;
이것은 코드의 특정 섹션을 테스팅하는 데 도움이 될 것입니다.

깨끗한 kmemleak으로 하고 싶을 때 크리티컬 섹션을 테스트하기 위해서는
이렇게 하세요:

  # echo clear > /sys/kernel/debug/kmemleak
  … 여러분의 커널이나 모듈을 테스트 …
  # echo scan > /sys/kernel/debug/kmemleak

그 후, 여느 때처럼 여러분의 보고서를 얻기 위해서:

  # cat /sys/kernel/debug/kmemleak

Kmemleak API
————

함수들의 프로토 타입은 /include/linux/kmemleak.h 헤더를 보세요.

kmemleak_init            – kmemleak 초기화
kmemleak_alloc           – 하나의 메모리 블록 할당 알림
kmemleak_alloc_percpu    – 하나의 percpu 메모리 블록 할당 알림
kmemleak_free            – 하나의 메모리 블록 해제 알림
kmemleak_free_part       – 하나의 부분 메모리 블록 해제 알림
kmemleak_free_percpu     – 하나의 percpu 메모리 블록 해제 알림
kmemleak_not_leak        – 누수가 아닌 것으로 객체 표시
kmemleak_ignore          – 스캔하지 않거나, 누수로 객체를 보고하지 않음
kmemleak_scan_area       – 메모리 블록내의 스캔 지역 추가
kmemleak_no_scan         – 메모리 블록 스캔하지 않음
kmemleak_erase           – 포인터 변수 안의 이전 값을 지움
kmemleak_alloc_recursive – kmemleak_alloc과 같지만 재귀성 검사
kmemleak_free_recursive  – kmemleak_free와 같지만 재귀성 검사

거짓 검출/미검출의 처리
———————–

거짓 미검출은 진짜 메모리 누수(주인없는 개체)가 메모리 스캐닝 중에 찾은 값들이
객체들을 가리키고 있어서 kmemleak에 의해 보고되지 않는 것입니다.
거짓 미검출의 수를 줄이기 위해서, kmemleak은 kmemleak_ignore,
kmemleak_scan_area, kmemleak_no_scan, 그리고 kmemleak_erase 함수들
(위를 보세요)을 제공합니다. 태스크 스택은 또한 거짓 미검출의 양을 늘려서,
그들의 스캐닝은 기본값으로 켜지지 않습니다.

거짓 검출은 객체들이 메모리 누수(주인없음)이 된 것처럼 잘못 보고되는 것입니다.
누수가 아닌 것으로 알려진 객체들을 위해서, kmemleak은 kmemleak_not_leak
함수를 제공합니다. kmemleak_ignore 또한 그 메모리 블록이 다른 포인터들을
포함하는 것으로 알려지지 않았다면 사용될 수 있고, 더 이상 스캔되지 않을
것 입니다.

보고된 누수들 중 어떤 것들은 CPU 레지스터나 스택 안에 임시적으로 저장되는
포인터들 때문에, 특히 SMP 시스템 상에서, 그저 일시적입니다. Kmemleak은
메모리 누수로 보고되는 객체의 최소 나이를 표시하는 (기본은 1000인)
MSECS_MIN_AGE를 정의합니다.

제한과 결점
———–

주요 결점은 메모리 할당과 해제의 성능을 떨어뜨린 다는 것 입니다. 다른 불이익을
피하기 위해서, 메모리 스캐닝은 /sys/kernel/debug/kmemleak 파일을 읽을 때만
수행됩니다. 어쨌든, 이 도구는 성능이 가장 중요한 요구 사항이 아닌 곳에서의
디버깅을 목적으로 합니다.

알고리즘을 간단히 유지하기 위해서, kmemleak은 한 블록의 주소 범위 안의
어떤 주소를 가리키는 값들을 스캔합니다. 이것은 거짓 미검출의 수를 늘릴 것입니다.
그러나, 그것은 진짜 메모리 누수가 결국 보여지게 되도록 할 것입니다.

거짓 미검출의 다른 출처는 포인터가 아닌 값들안에 저장된 데이터입니다. 이후
버전에서는 kmemleak이 할당된 구조체 안의 포인터 멤버만 스캔할 수 있을 것입니다.
이 기능은 위에서 설명한 많은 거짓 미검출을 해결할 것 입니다.

이 도구는 거짓 검출을 보고할 수 있습니다. 할당된 블록이 해제를 필요로 하지 않는
곳(init_call 함수 안의 어떠한 경우), 그 포인터가 보통의 container_of
매크로가 아닌 다른 방법으로 계산되는 곳, 또는 그 포인터가 kmemleak이 스캔하지
않는 위치 안에 저장된 포인터인 곳 같은 경우들이 있습니다.

페이지 할당과 ioremap은 추적하지 않습니다.

[Linux] 새로 깔면 하는 환경 변수 셋팅

새로 깔면 하는 환경 변수 셋팅(~/.bashrc)

export ANDROID_JAVA_HOME=”/usr/lib/jvm/jdk1.6.0_38/”
export JAVA_HOME=”/usr/lib/jvm/jdk1.6.0_38/”
export PATH=”~/bin:$PATH:/usr/lib/jvm/jdk1.6.0_38/bin”

alias setcross=’export CROSS_COMPILE=”/opt/toolchains/arm-eabi-4.6/bin/arm-eabi-“‘
alias b=”. ~/bin/backdir.sh”

export USE_CCACHE=1

backdir.sh 는 [Bash] cd ../../../../.. 을 치기 귀찮을 때 유용한 스크립트에 있다

부동산 상속 등기 셀프 등기

대법원 등기소 콜센터(1544-0770) 전화해서 등기 절차 문의

1. 상속등기위임장 작성(상속인 중 출석이 어렵다면, 인감 증명서 등의 서류를 받은 후 작성)
    부동산의 표시 : 등기부 상 부동산의 표시와 일치하도록 상속 부동산을 기재
        예) 건물 서울특별시 OO구 OO동 OO번지 연와조 슬라브위기와 2층 주택 1층 OO.O㎡, 2층 OO.O㎡
             토지 서울특별시 OO구 OO동 OO번지. OO.O㎡
    등기의 목적 : 소유권이전등기신청(협의분할에 의한 상속)
    위임인 : 위임을 하는 자의 성명과 주소를 기재하고 날인(도장 필요)
    수임인 : 위임을 받는 자의 성명과 주소를 기재(도장 필요)

2. 상속재산분할협의서 작성
공동상속인 모두의 서명과 날인(인감 도장)이 필요.
cfile30.uf.2647603B530F6EAD0F995C.hwp

3. 모든 상속인의 인감 증명서 및 인감 도장 준비해서 구청 방문해서 다음 서류 발급
    사망자의.. 제적등본, 할아버지의 전제적등본, 기본증명서, 가족관계증명서, 친양자입양관계증명서, 혼인관계증명서, 주민등록등(초)본
    상속인의.. 기본증명서, 가족관계증명서, 주민등록등(초)본, 인감증명서
    토지대장, 건축물 대장

4. 구청 내의 부동산 증세 관련 부서(세무과-민원실)에 가서 등록세 영수필 확인서 발급
    미리 전화로 취득세 및 등록세 금액 확인이 가능함.
    필요서류 : 상속재산분할협의서, 사망자의 기본증명서, 사망자의 가족관계증명서, 피상속인의 주민등록초본, 상속인 모두의 주민등록등초본, 토지대장(등기소에서도 필요), 건축물대장(등기소에서도 필요), 신분증, 인감도장(혹은 위임장)

    1가구 1주택으로 인하여 취득세 비과세가 되는 경우는 1가구 1주택 확인서를 구청에서 발급받고 상속인의 주민등록등본, 가족관계증명서를 함께 제출하면 바로 취득세가 0원으로 기재된 OCR용지가 발급된다.
    시,구,군청에 세금납부창구가 있는 경우에는 그곳에서 납부 가능, 아니면 은행.
    세금 납부 시 반드시 고지서에 확인 도장을 받아야하고 그 중 등기소 제출용(도장이 찍힌 등기소 제출용 고지서)을 챙긴다.


5. 은행에서 취득세(등록세가 취득세에 포함됨) 납부

    비용은 구청의 부동산 증세 관련 부서 혹은 해당 등기소 직원에게 문의.(신용카드 납부 가능)
    발급받은 OCR 용지로 은행에서 납부.(카드 납부 가능하다고 들었으나, OCR 공과금 납부가 가능한 은행에서만 가능. 경기도 성남의 경우 등기소 별관3에 있는 우리은행에는 없어서 현금으로 납부했다.)
    취득세 비용은 등기소 콜센터에 전화하면 안내해준다. 세율을 곱한 결과를 5000원 단위로 반올림한다. 3225000원이라면, 3230000원).

6. 은행에서 국민주택채권 매입
    국민주택채권을 사서 보유한다면 해당 금액 만큼의 현금이 있어야 하고, 바로 되판다면, 차액만큼만 지불하면 된다.

7. 은행에서 등기 비용 납부
    국민주택채권을 살 때, 등기 비용도 함께 납부한다. 성남 법원에서 인지세 대신 등기비용으로 납부.
    부동산 한 건당 15000원. 토지와 건물이라면 토지 15000 + 건물 15000 = 총 30000원이 된다.

8. 등기과에서 등기 신청서를 작성한 후, 모은 자료와 함께 제출.

이제는 E-Form을 이용한 셀프 등기에 도전해보자.

참고 자료

샐린져 양의 셀프상속등기안내
부동산 상속등기 셀프 등기하기 in 강아지와 자유인의 행복공간
쉬운 셀프상속등기 완결판 in 란마의 맛있는 이야기
셀프 상속 등기 시 절차 및 준비 서류 in Que Sera Sera

2014.02.21.소치 올림픽 김연아 현역 마지막 경기

밴쿠버 올림픽 때 김연아가 금메달 딴 다음 날 점심,
나는 김연아가 좋다고, 나는 김연아’빠’가 맞다고, 그 연기가 너무 예쁘다고, 내가 김연아와 동시대에 존재한다는게 얼마나 다행이고 행복한지 모를거라고 하는 내 말에,
시니컬하게 “형, 그 기록이 안깨질 것 같아? 그거 어차피 깨져” 라고 대꾸하는 녀석의 말에,
발끈했지만 그저 웃고 넘긴 것이, 한마디 톡 쏴주지 못한 것이 두고두고 맘에 남을 정도로, 나는 김연아를 좋아한다.

이번 올림픽 출전을 마지막으로 은퇴할 거라는 말에, 마지막 경기 만큼은 그녀가 후회로 남지 않을 연기를 하기를 바랐다. 점프를 뛸 때마다 ‘넘어지더라도 그 때 안 뛴 것을 후회하지 않게 그냥 뛰어’와 ‘아, 넘어져서 후회로 남으면 안되는데’ 하는 두 모순된 마음에 나도 내 마음을 몰라 했다. 출전 전에 목표가 클린 연기라는 그 말에 끄덕이며, ‘점수나 메달 따윈 상관없어. 연아만 좋다면’ 했지만, 막상 닥쳐 “말도 안돼!” 가 저절로 나오는 걸 보니 정말 그렇지는 않았던 모양이다. 괘씸하다.

그래도 웃으며 마무리 지은 그녀의 모습이, 곰인형을 주워 끌어안고 재기 넘치는 표정을 짓고, 빙판에서 내려오면서 갑자기 울컥하던 그 모습이, 다시금 떠오른다.
밴쿠버 올림픽 때의 프리 경기에서의 마지막 스핀을 돌 때, 심장이 쿵쾅거리며 환희에 눈물이 날 것 같았던 그 느낌을, 마지막에 두 팔을 번쩍 들고 기뻐하던 모습도, 울음을 떠뜨린 그 얼굴을 보며 나도 눈가가 젖어오던 그 느낌도 떠오른다.

내가 동시대에 함께 있어서, 지금껏 한 시대의 역사를 직접 보고, 그것을 느낄 수 있어서 정말 행복했다.
그리고 내 마음에 주었던 감동도 잊지 못한다.

[Linux:Kernel] PM Quality Of Service 인터페이스

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).
Documentation/power/pm_qos_interface.txt
번역: 양정석(dasomoli@gmailREMOVETHIS.com)
PM Quality Of Service 인터페이스.
이 인터페이스는 커널과 유저 모드에 그 파라미터 중 하나로 드라이버, 서브 시스템,
그리고 유저 공간 애플리케이션들에 의한 성능 기대 사항을 등록하기 위한
인터페이스를 제공합니다.
두가지 다른 PM QoS 프레임워크가 이용가능합니다:
1. cpu_dma_latency, network_latency, network_throughput을 위한 PM QoS 클래스들.
2. per-device PM QoS 프레임워크는 per-device 지연 제약 사항과 PM QoS 플래그를
관리하기 위한 API 를 제공합니다.
각 파라미터는 단위를 정의했습니다:
 * 지연(latency): usec
 * 만료(timeout): usec
 * 처리용량: kbs (킬로 비트 / 초)
1. PM QoS framework
이 인프라 구조는 여러개의 misc 디바이스 노드들을 구현된 파라미터 당 하나로
노출합니다. 파라미터들 구현 집합은 pm_qos_power_init() 과 pm_qos_params.h 에
의해 정의됩니다. 드라이버로부터 런타임에 설정 가능하거나 변경 가능한 사용 가능
파라미터들을 갖는 것이 오용되기 너무 쉬운 것으로 보여지기 때문에 이렇게
수행됩니다.
각 파라미터를 위해 성능 요구에 대한 리스트가 취합된(aggregated) 목표 값으로
관리됩니다. 취합된 목표 값은 그 요구 목록이나 그 리스트의 개체들로의 변경으로
갱신됩니다. 일반적으로 그 취합된 목표 값은 간단히 파라미터 리스트 개체들 안에
잡힌 요청 값의 최고 또는 최저 값입니다.
알림: 그 취합된 목표 값은 어토믹(atomic) 변수로 구현됩니다. 그래서 취합된 값을
읽는 것은 어떤 락킹 메카니즘도 필요 없습니다.
커널 모드로부터 이 인터페이스의 사용은 간단합니다:
void pm_qos_add_request(handle, param_class, target_value):
는 개체 하나를 그 리스트 안에 목표 값으로 식별된 PM QoS 클래스를 위해 삽입할
것입니다. 이 리스트로의 변경 위에서 새로운 목표는 재계산되고, 어떤 등록된
통지자(notifier)가 그 목표 값이 지금과 다를 때만 호출됩니다. pm_qos의
클라이언트는 다른 pm_qos API 함수들 안에서 추후에 사용될 때를 위해 반환된
핸들을 저장할 필요가 있습니다.
void pm_qos_update_request(handle, new_target_value):
는 그 핸들이 가리키는 리스트 개체를 새로운 목표 값으로 갱신하고, 그 목표가
바뀌면 취합된 목표, 통지(notifictation) 트리 호출을 재계산합니다.
void pm_qos_remove_request(handle):
는 개체를 제거합니다. 제거 후에는 취합된 목표를 갱신하고, 그 목표가 요청 제거의 결과로 바뀌면, 통지 트리를 호출할 것입니다.
int pm_qos_request(param_class):
는 주어진 PM QoS 클래스를 위한 취합된 값을 반환합니다.
int pm_qos_request_active(handle):
는 그 요청이 여전히 살아있는지를 반환합니다. 즉, PM QoS 클래스 제약 사항 리스트
로부터 제거되지 않았다는 것입니다.
int pm_qos_add_notifier(param_class, notifier):
는 통지 콜백 함수를 PM QoS 클래스로 추가합니다. 그 콜백은 PM QoS 클래스를 위한
취합된 값이 바뀌었을 때 호출됩니다.
int pm_qos_remove_notifier(int param_class, notifier):
는 PM QoS 클래스를 위한 통지 콜백 함수를 제거합니다.
유저 모드에서는:
프로세스들만 pm_qos 요청을 등록할 수 있습니다. 프로세스의 자동적인 청소 작업을
제공하기 위해서, 인터페이스는 프로세스에게 다음과 같은 방법으로 그 파라미터
요청을 등록하도록 요구합니다:
지정된 파라미터의 기본 pm_qos 목표를 등록하기 위해서, 프로세스는
/dev/[cpu_dma_latency, network_latency, network_throughput] 중 하나를
열어야만 합니다.
디바이스 노드가 연 것을 유지하는 동안 그 프로세스는 파라미터 상의 등록된
요청을 가집니다.
요청된 목표 값을 변경하기 위해서, 그 프로세스는 s32 값을 열린 디바이스 노드에
쓸 필요가 있습니다. 아니면, 유저 모드 프로그램이 16진수 문자열을 10 글자 길이의
형식의 값, 예를 들면, “0x12345678″로 쓸 수 있습니다. 이것은 pm_qos_update_request
호출로 변환됩니다.
목표 값의 유저 모드 요청을 지우려면, 간단히 디바이스 노드를 닫으세요.
2. PM QoS per-device 지연 프레임워크
각 개별 디바이스를 위한 성능 요청의 리스트는 취합된 목표 값으로 관리됩니다.
취합된 목표 값은 요청 리스트나 그 리스트의 개체로의 변경으로 갱신됩니다.
일반적으로 그 취합된 목표 값은 간단히 파라미터 리스트 개체 안에 잡힌 요청 값의
최고, 또는 최소 값입니다.
알림: 그 취합된 목표 값은 어토믹(atomic) 변수로 구현됩니다. 그래서 취합된 값을
읽는 것은 어떤 락킹 메카니즘도 필요 없습니다.
커널 모드로부터 이 인터페이스 사용은 다음과 같습니다:
int dev_pm_qos_add_request(device, handle, value):
는 개체 하나를 그 리스트 안으로 목표 값으로 식별된 디바이스를 위해 삽입할
것입니다. 이 리스트로의 변경 위해서 새로운 목표는 재계산되고, 어떤 등록된
통지자가 그 목표 값이 지금과 다를 때만 호출됩니다. dev_pm_qos의 클라이언트는
다른 dev_pm_qos API 함수들 안에서 추후에 사용될 때를 위해 그 핸들을 저장할
필요가 있습니다.
int dev_pm_qos_update_request(handle, new_value):
는 그 핸들이 가리키는 리스트 개체를 새로운 목표 값으로 갱신하고, 그 목표가
바뀌면 새로운 취합된 목표, 통지 트리 호출을 재계산합니다.
int dev_pm_qos_remove_request(handle):
는 개체를 제거합니다. 제거 후에는 취합된 목표를 갱신하고, 그 목표가 요청 제거의
결과로 바뀌면, 통지 트리를 호출할 것입니다.
s32 dev_pm_qos_read_value(device):
주어진 디바이스의 제약 사항 라스트를 위한 취합 값을 반환합니다.
통지 메카니즘:
per-device PM QoS 프레임워크는 2개의 다르고 구별되는 통지 트리를 가집니다:
per-device 통지 트리와 전역 통지 트리
int dev_pm_qos_add_notifier(device, notifier):
디바이스를 위한 통지 콜백 함수를 추가합니다.
디바이스 제약사항 리스트의 취합된 값이 바뀔 때, 콜백이 호출됩니다.
int dev_pm_qos_remove_notifier(device, notifier):
디바이스를 위한 통지 콜백 함수를 제거합니다.
int dev_pm_qos_add_global_notifier(notifier):
프레임워크의 전역 통지 트리 안에 통지 콜백 함수를 추가합니다.
어떤 디바이스를 위한 취합된 값이 바뀔 때, 콜백이 호출됩니다.
int dev_pm_qos_remove_global_notifier(notifier):
프레임워크의 전역 통지 트리로부터 통지 콜백 함수를 제거합니다.
유저모드에서는:
per-device 지연 제약 사항으로의 유저 공간 접근을 위한 API는 아직 제공되지
않습니다. – 아직 토의 중.

[Linux:Kernel] CPU 토폴로지

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/cputopology.txt

번역: 양정석(dasomoli@gmailREMOVETHIS.com)

CPU 토폴로지는 sysfs를 통해 노출됩니다. 항목(속성들)은 /proc/cpuinfo와
유사합니다.

1) /sys/devices/system/cpu/cpuX/topology/physical_package_id:

        cpuX의 물리적인 패키지 ID. 일반적으로 물리적인 소켓 번호에
        해당하지만, 실제 값은 아키텍처와 플랫폼에 따라 다릅니다.

2) /sys/devices/system/cpu/cpuX/topology/core_id:

        cpuX의 CPU 코어 ID. 일반적으로 (커널의 것 보다는) 하드웨어
        플랫폼의 식별자입니다. 실제 값은 아키텍처와 플랫폼에 따라
        다릅니다.

3) /sys/devices/system/cpu/cpuX/topology/book_id:

        cpuX의 Book ID. 일반적으로 (커널의 것 보다는) 하드웨어 플랫폼의
        식별자입니다. 실제 값은 아키텍처와 플랫폼에 따라 다릅니다.

4) /sys/devices/system/cpu/cpuX/topology/thread_siblings:

        cpuX와 같은 코어 내부의 cpuX의 하드웨어 스레드들의 내부 커널 맵

5) /sys/devices/system/cpu/cpuX/topology/core_siblings:

        같은 물리적 패키지 ID(physical_package_id) 내부의 cpuX의
        하드웨어 스레드들의 내부 커널 맵

6) /sys/devices/system/cpu/cpuX/topology/book_siblings:

        같인 Book ID(book_id) 내부의 cpuX의 하드웨어 스레드들의 내부
        커널 맵

아키텍처에 자연스러운 방법으로 구현하기 위해서, 새로운 소스 파일,
drivers/base/topology.c는 4 에서 6 개의 속성들을 드러냅니다. sysfs
파일들에 관련된 두 book 은 CONFIG_SCHED_BOOK 이 선택되었을 경우에만
생성될 것입니다.

이 기능을 지원하는 아키텍처를 위해서, include/asm-XXX/topology.h 안에
이들 매크로들 중 몇가지가 정의되어야만 합니다:
#define topology_physical_package_id(cpu)
#define topology_core_id(cpu)
#define topology_book_id(cpu)
#define topology_thread_cpumask(cpu)
#define topology_core_cpumask(cpu)
#define topology_book_cpumask(cpu)

**_id의 타입은 int 입니다.
sibling의 타입은 (const) struct cpumask * 입니다.

모든 아키텍처에 일관되도록, include/linux/topology.h 는
include/asm-XXX/topoloty.h 에서 정의하지 않는 위들 매크로 중 무엇을 위한
기본 정의를 제공합니다:
1) physical_package_id: -1
2) core_id: 0
3) thread_siblings: 그냥 주어진 CPU
4) core_siblings: 그냥 주어진 CPU

Book(CONFIG_SCHED_BOOK)을 지원하지 않는 아키텍처에는 topology_book_id() 와
topology_book_cpumask() 의 기본 정의가 없습니다.
추가적으로, CPU 토폴로지 정보는 /sys/devices/system/cpu 아래에서 제공되고,
이들 파일을 포함합니다. 출력의 내부 소스는 브라켓들(“[]”) 안에 있습니다.

    kernel_max: 커널 설정[NR_CPUS-1]에서 허용되는 최고 CPU 인덱스

    offline:    핫플러그 오프(HOTPLUGGED off:cpu-hotplug.txt 참고)되었거나,
                커널 설정(위의 kernel_max)에서 허용되는 CPU들의 제한을
                초과핬기 때문에 온라인이 아닌 CPU들.
                [~cpu_online_mask + cpus >= NR_CPUS]

    online:     온라인이고 스케줄 중인 CPU들 [cpu_online_mask]

    possible:   자원을 할당받았고, 지금 존재하면 온라인이 될 수 있는
                CPU들. [cpu_possible_mask]

    present:    시스템에 현재 존재하고 있는 것으로 식별된 CPU들.
                [cpu_present_mask]

위 출력의 형식은 cpulist_parse()[<linux/cpumask.h>]와 호환됩니다.
아래 예제가 있습니다.

이 예제에서, 64개의 CPU들이 시스템 내부에 있지만, CPU 32-63은 32로
된 NR_CPUS 설정 옵션에 의해 0..31 로 제한된 커널 최고값을 초과했습니다.
CPU 2와 4-31들은 온라인이 아니지만, 존재(present)하고, 가능(possbile)하므로
온라인이 될 수 있습니다.

     kernel_max: 31
        offline: 2,4-31,32-63
         online: 0-1,3
       possible: 0-31
        present: 0-31

이 예제에서, NR_CPUS 설정 옵션은 128이지만, 커널은 possible_cpus=144로
시작되었습니다. 시스템 내에 4개의 CPU가 있고, cpu2는 수동으로 오프라인이
되었습니다(그리고, 그 하나의 CPU만 온라인이 될 수 있습니다).

     kernel_max: 127
        offline: 2,4-127,128-143
         online: 0-1,3
       possible: 0-127
        present: 0-3

possible_cpus=숫자 시작 파라미터는 다양한 cpumask 의 더 많은 정보로
좋은 cpu-hotplug.txt 를 보세요.