#define pr(a, b...) printf(a, b) /* (*A) */
#define pr(a, b...) printf(a, ##b) /* (*B) */
pr("Hello\n"); /* (*1) */
pr("Hello %s\n", "World"); /* (*2) */
pr("Hello %s %s\n", "My", "World"); /* (*3) */
Above two kinds of macros looks like same at first look. But, there is difference.
In case of (*2) and (*3), (*A) and (*B) both work well.
In terms of (*1), it doesn't have second arguement. That is, it doesn't have arugment 'b'.
So, let's guess result of preprocessing.
Logically, in both case - (*A) and (*B) - "printf(a, )" should be a result, and GCC should complain about this syntax.
But, actual result is, (*A) doesn't work, but (*B) works well.
I didn't check GCC Spec. for this case but, it's interesting enough to leave post :-).
Interesting rule of GNU make.
Dependency can be defined more than one place. It’s very interesting.
Syntax : Take you attention that there is NO command in rule.
<target> : <dep>
At abve case, <dep> is ADDED to <target>’s existing dependency (NOT “replace”!!)
But, if there is COMMAND at above rule, old COMMAND is “REPLACED” (NOTE that, dependency is still ADDED).
See below examples to help understanding.
< Makefile >
all: a
touch all0
a
touch a
all: b
b
touch b
> make
touch a
touch b
touch all0
———————-
< Makefile >
all: a
a
touch a
all: b
touch all1
b
touch b
> make
touch b
touch a
touch all1
———————-
< Makefile >
all: a
touch all0
a
touch a
all: b
touch all1
b
touch b
> make
touch b
touch a
touch all1
# Same with above
# That is, older command for target is replaced with newer one.
[Essay] 리더로서 자연스럽게 팀의 업무 상황 파악하기…
리더가 팀을 이끌어 과는 과정에서 팀원의 업무 파악은 상당히 중요한 일이다.
업무 파악을 위해서 가장 많이 하는 일은 다음과 같은 것들이 있다.
– 주간 업무 회의 : 주 1회 정도 정기적인 업무 회의를 통해서 보고 받는다.
– E-mail 참조 : 업무관련 E-mail 을 주고 받을때, 리더를 CC에 넣도록 한다.
– 식사/커피 등 함께 하기 : 자연스러운 분위기에서 업무 관련 이야기를 듣고자 한다.
다 좋다. 필수 적이기도 하다.
그렇지만 위의 것들을 모두 잘 하고 있음에도 불구하고, 늘 팀원의 업무 파악이 제대로 되지 않는 것 같다고 느끼는 경우도 있다.
무엇이 문제인가?
내가 생각하기에, 위의 방법들도 좋지만, 가장 중요한 것은 팀원들이 리더에게 도움을 받을 수 있어야 하고, 팀원이 이를 실질적으로 느끼고 있어야 한다는 것이다.
예를 들면, 어떤 문제에 대해서 실무자가 자기 자신의 힘만으로는 해결이 힘들어서 리더에게 보고를 하는 경우를 생각해보자.
이런 문제의 경우 대부분이 내부에서 실무적으로 처리하기는 한계가 있다고 실무자가 판단하는 경우이다.
즉, 외부 혹은 타 부서와의 협력을 통해 문제를 해결할 필요가 있는 문제이다.
이때, 리더가 취하는 가장 일반적인 자세는, 일단 무엇이 문제인지 문제를 파악하고자 한다. 그래서 실무자에게 관련 문제에 대한 문답이 이루어진다. 여기까지는 자연스러워 보인다.
그런데 이후, 물론 리더에 따라 다르겠지만, 실무적인 가이드를 시작하는 경우가 있다. 그리고 이런 경우는 대부분, 상당한 시간을 소모함에도 불구하고, 리더가 제시한 가이드가 해결에 도움이 되기 보다는, 리더가 문제에 대해 더 잘 이해하는데 도움이 되는 정도로 끝난다.
이 과정이 반복되면, 일단 실무자는 피로를 느끼게 된다.
최악의 경우는, 리더가 실무에 대한 잘못된 가이드를 제시하고, 실무자의 의견에 반하여 그 가이드에 따라 일을 진행시키라고 강요하는 경우다.
이런 리더에게 실무자는 어떠한 도움도 구하고자 하지 않는다.
그리고 이후, 리더는 자신의 실무적인 해결책에 도움이 되지 못하게 됨을 깨닫고, 실무자에게 어떤 도움이 필요한지를 묻게 되고, 실무자는 ” xxx가 필요합니다.”라는 말을 하게 된다. 이런 도움의 대부분은 타 부서와의 업무 협조, 상위 부서에 보고 등에 대한 문제이다.
실무자가 요구한 사항을 리더가 해결해 주는 것이 정상적이나, 어떤 리더의 경우는 “그래? 그럼 xx씨가 직접 oo한테 연락해서 처리하도록.”의 식으로 결국 실무자가 모든 일을 해야 하는 방향으로 결정을 내리기도 한다.
자. 위에서 문제가 된다고 생각하는 과정을 거친 실무자의 입장에서 보면, 본인이 진행하는 업무에 문제가 있어서 리더에게 보고를 했을때, 업무 진행에 도움을 받기 보다는, 시간과 에너지를 소모하고, 결국 자기 자신이 처리해야 하는 방향으로 결론이 난 것이다.
즉, 문제를 보고하는게 하등 도움이 되지 않는 것이다.
실무자가 이렇게 느낀다면, 과연 이후 업무에 대해서 리더에게 보고하려고 할까?
그냥 정기적인 보고 이외 특별히 리더와 업무에 대해 상의하고자 하지 않을 것이다.
어차피 결과적으로는 자기 자신이 모두 처리해야 하니까…
주저리주저리 이야기가 길었다.
간단하게 결론을 정리하면, 리더가, 실무자에게 도움을 줄 수 있고, 또 그렇다고 실무자가 느낀다면, 리더는 자연스럽게 실무자가 가지고 있는 문제를 보고 받게 되고, 팀원들이 업무적으로 가지는 문제가 무엇인지 이해할 수 있게 된다는 말이다.
직설적으로 이야기 하면, 맨날 보고 안한다고 뭐라고 하지 말고, 실무에 도움이 좀 되란 말이다. 그럼 자연스럽게 팀원들이 보고하게 될테니까…
실무적으로 아는게 없다고 해서 팀원들에게 도움을 줄 수 없다는 말은 하지 말자. 외부와의 소통문제, 업무 협조 요청 등등 수많은 일들로 팀원들을 도울 수 있으니…
[Kernel] How to know KBUILD_MODNAME of each files.
Kernel build system defines KBUILD_MODNAME automatically from each Makefile.
You can easily find below string from build command of each files of modules.
-D"KBUILD_MODNAME=KBUILD_STR(xxxxx)"
('xxxxx' is given module name)
This name xxxxx comes from Makefile.
Below is simple example.
[ in Makefile ] xxxxx-y := a.o b.o c.o d.o
In above case, KBUILD_MODNAME of a.c, b.c, c.c and d.c becomes xxxxx.
This can be easily confirmed by checking command line of each objects – a.o, b.o, c.o and d.o.
[Essay][시사]진정성이 중요한 이유…
유시민 전 장관께서 예전에, 서울대학교 강연에서 “진정성은 중요치 않다. 제시한 정책이 좋냐, 나쁘냐로 판단해야 한다.”라고 하셨던 것이 생각난다.
유 전 장관님의 이야기는 아마도, “초점을 정책 자체에 두라!”라는 의미였을 것이다. “정책은 정책 자체로 평가되어야 하지 외부적인 요소가 개입되면 안되다는 뜻” 이 아닐까? 난 그 말에 전적으로 동의한다.
그렇지만, 여기에 내 개인적인 생각을 약간 첨언하고자 한다.
정책을 판단할때 가장 중요한 요소는 정책 자체이다. 그런데 문제는, 정책이 “좋냐, 나쁘냐”를 판단할 수 있는 경우 만큼이나, 판단할 수 없는 경우도 많다는 것이다.
예를 들어, FTA (굳이 이번 한미 FTA가 아니더라도)에 대해서 생각해보자.
FTA로 인해 명백하게 이익이 되는 혹은 명백하게 손해가 나는 사람들이 분명히 존재한다. 그런 사람들이 FTA를 판단할 때는 정책자체 – FTA는 정책이 아니긴 하지만… 따지지 말자. – 를 놓고 찬성/반대 하면 된다.
그렇지만, 애매한 사람들도 많다. 이게 국민에게 – 라고 말하지만, 사실은 ‘나’에게 – 이익이 되는지 손해가 되는지 도무지 판단할 수 없는 사람들 말이다. 정부, 또 각종 언론 등에서 이런 저런 예측 수치를 내 놓지만, 그건 단지 예측일 뿐이다. 그것도 적중률이 상당히 떨어지는…
이럴 경우는 무엇을 근거로 정책에 대한 찬성/반대를 해야할 것인가?
이럴 때 ‘진정성’ 이 다시 중요해진다.
확률적으로, 정치인이 ‘진정’으로 “이것이 국가/국민에게 이익이 된다.”라고 믿고 추진하는 정책이, 정치인 개인의 이익에 근거해서 추진되는 것보다는, 국민/나 에게 이익이 될 확률이 높기 때문이다.
물론, ‘진정성’을 정확히 판단하는 것은, 정책 그 자체를 판단하는 것 만큼이나 어려울 것이다.
그렇지만, 특정 정치인의 삶의 발자취에 근거한 ‘진정성’에 대한 판단은 신뢰할 만하지 않을까?
그래서, 많은 사람들이 ‘진정성’에 대해 이야기 하고, 또 고민하는 것이 아닐까?
(물론, 특정 정치인의 삶의 발자취를 ‘제대로’ 분석하는 것이 쉬운일은 아닐테지만… – 그래서 언론의 역할이 중요한데, 이건 뭔…쩝…)
[Essay] 개인이 자체 개발 SW를 회사에 공개하지 않는 이유…
회사에서 근무하는 개발자들 가운데, 개발 자체를 좋아하거나, 혹은 기술을 숙련시키는 과정의 한 방법으로 자체적으로 SW를 개발하는 사람들이 있다. 대부분의 경우, 개인이 제한된 시간안에서 prototyping하는 정도일 것이다. 그렇지만, 그 중 몇몇은 조금만 개선/발전 시킨다면, 제법 괜찮은 SW의 근간이 되는 것들도 있을 것이다.
대표적으로, Google의 경우 20%의 시간은 개발자가 자기가 하고 싶은 것을 하도록 두는데, 여기서 나온 산물을 회사차원에서 지원해서 제품으로 발표한 것들도 적지 않은 숫자가 된다고 알고 있다.
그런데, 국내 개발자들 대부분이 자신이 틈틈이 개발한 SW를 회사에 공개하는 것을 극도로 꺼려한다.
왜 그럴까?
근본적으로 지적 재산권 문제가 걸린다. 물론 회사마다 정책이 다르겠지만, 국내 대부분의 회사에서는, 개발자가 자체개발 SW를 회사측에 공개하는 즉시 지적 재산권 전부를 회사에 넘겨준다고 보는 것이 좋다 – 국내 대부분의 회사의 고용계약서의 위의 사항이 명시되어 있다. 따라서, 내가 잠자는 시간을 줄여가며, 여가시간을 희생해 가면서 만든 SW를 아무런 대가 없이 회사에 넘겨 주는 것은 그리 유쾌한 일은 아니다.
그렇지만, 만약 공개한 SW가 회사의 지원을 받게 되고, 개발자 본인이 그 일에 참여할 수 있다면, 지적 재산권을 넘겨주는 손해도 충분히 감수할 만한 경우도 있다. 사실 자신의 SW를 회사에 공개하는 개발자의 대부분은 이런 결과를 기대했었을 것이다.
물론 의도한 대로 진행되면 좋겠지만, 회사의 판단이 개인의 판단과 달라서, 개발자 개인은 충분히 가치있다고 생각되는 SW를 회사에서 사장시키기로 결정했을 경우 문제가 복잡해진다.
이런 상황에서 개발자는 자신의 꿈과 열정이 담긴 SW의 가치를 믿고 계속 발전시켜 나가고자 하지만, 이미 지적재산권이 회사로 넘어간 이후이므로 그렇게 할 수가 없다. 왜냐하면, 개발자 개인이 아무리 많은 열정과 노력을 해당 SW에 쏟는다고 하더라도 모든 권리는 회사의 것이기 때문에 말 그대로 “죽 쒀서 개 주는 꼴” 밖에 되지 않기 때문이다.
즉, 원작자는 눈물을 머금고 자신의 SW가 사장되는 것을 지켜볼 수 밖에 없어진다.
이러니, 어떤 개발자가 자신의 SW를 회사에 공개하려고 하겠는가?
위와 같은 구조는 개인과 회사 모두에게 손해가 된다.
개인이 혼자서 SW개발을 하는 것은 분명히 한계가 있으므로, 개발자는 자신이 생각하는 내용의 SW를 완성시키기 위해 너무 많은 노력이 든다 (회사의 지원을 받을 수 없으므로). 반대로 회사는 충분히 좋은 idea의 SW들을 제공받을 수 있는 통로 하나를 상실한다.
이런 문제를 해결하기 위한 해결책은 없을까? 내 개인적인 생각은 아래와 같다.
기본적으로, SW의 지적 재산권은 회사가 가진다.
그렇지만, 공개된 SW에 대한 특정 심사 기간을 두고 (ex. 3개월), 회사에서 해당 SW를 사장시키기로 결정했다면, 해당 SW에 대한 지적 재산권을 개발자 개인에게 돌려 주는 것이다. 반대로, 만약 SW가 지원할 가치가 있다고 판단되면, 개발자에게 관련 중책을 맡긴다.
위와 같은 정책이 정직하게 운영되는 회사라면 아마도 많은 SW개발자들이 자신의 SW를 회사에 공개하지 않을까… 조심스럽게 생각해 본다.
[Kernel] Analyzing linux kernel Oops report easily…
In Linux, usually, kernel crashes with so-called Oops report.
This Oops report includes lots of useful information for debugging.
Therefore, I have seen lots of developer suffering from analyzing register, memory and stack dump in the report.
To analyze dumped information, memory information should be matched with source code.
But, this is not easy process.
So, I want to introduce the way to do this easily.
Main concept is, we can make tool to parse Oops report and pass these to debugging tool.
Here is introduction of my case.
I uses TRACE32 software – ARM simulator for debugging tool.
What I did is, implementing simple Perl script that parses Oops report and make cmm file that set register and memory information given by the report.
For example, auto generated cmm file is like this.
R.S cpsr 0x20000013 R.S r0 0x0 R.S r1 0x0 ... D.S 0xc035a248 %long 0xe3a02000 D.S 0xc035a24c %long 0xe3a03020 ...
It’s time to use TRACE32 PowerView for ARM to analyze the report.
Launching t32marm with simulator mode -> Loading issued ‘vmlinux’ -> Runnig auto-generated cmm script
Finally, I can see stack frame with local variables and interpreted memory information by virtue of T32.
I’m sorry not to share parsing tool – Perl script – due to … as you know, something like legal issue… (I hate this.)
I hope this post is helpful for others…
[C/C++/JAVA] 변수를 block중간에 선언하는 방법에 대한 단상.
변수는 사용하기 직전에 선언하는 것이 원칙인데.. 문제는 scope다.
C/C++/JAVA에서 명시적으로 ‘{ }’를 통해서 scope를 잡아주지 않으면, 이후에도 계속 해당 변수가 살아있는 상태가 되어서 좋지 못하다.
그래서 ‘{ }’를 사용해서 scope를 제한해 주는 것이 좋은데, 그렇게 하면, indentation에서 괜시리 한칸 들여쓰여지게 되어 미관상 – 개인적으로 – 마음에 안든다…
음…
변수의 scope를 위한 이~~쁜~~ syntax가 있었으면 좋았을텐데… 라는 생각이 그냥 들어서…
[Review][Game] 총망라…
그로우랜서 게임 리뷰를 하면서.. 갑자기… 그 동안 내가 즐겼던 게임들이 떠올랐다.
각각에 대해 리뷰를 쓸수는 없겠지만… 언급이라도 하고 싶어서… 이곳에 한꺼번에 적는다.
생각날때마다 update할 예정…
Diablo : 1, hellfire, 2, expansion [특히 2]
: 미친듯이 했다. 하드코어 아시아 랭킹 30위 귄이였었다는…-_-;
Baldur’s gate 1, 2, shadow of amn, throne of bhaal:
: 더 말해 무엇하랴. 생에 최고의 RPG중 하나. Dungeon and Dragons와 Forgotten Realms를 알게 해준 게임.
Never Winter Nights
: Bioware사랑해요~~
Icewind Dale
: 엔딩은 못 봤지만…
Might And Magic 6,7,8
: 3대 RPG는 아무나 가질 수 있는 title이 아니다!
Heros Of Might And Magic 2,3,4,5
: 미친듯이 했던 2 (블랙드래곤 짱.) 완전히 망했던 4. 그래도 역시 잼있음.
Kings Bounty – The Legend / Armored Princess
: HOMM의 원조격. 그렇지만 역시 재미는 HOMM이 더…
Startcraft
: 말이 필요없음! 쵝오~!
Civilization 2,3,4
: 악마게임…
Master Of Orion 2
: 이것도.. 악마.. (이것도 시드마이어 였던가???)
Final Fantasy 5,6,7,8,9
: 일본식 RPG의 정수! 특히 개인적으로 5, 7
Elder Scroll 1(Arena), 2(Dagger fall), 3, 4
: 이거야 말로… 자유도를 추구하는 RPG의 최고봉… 특히나, Daggerfall !! (베데사다 15주년으로 꽁짜로 풀렸어요~~)
삼국지 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
: 삼국지를 좋아하니까..
신장의야망 혁신
: 일본을 좋아하진 않으나 게임의 완성도 면에서는…
용의기사
: 단순하게 즐길수 있는 SRPG…
용기전승
: 역시 SRPG. 수작이긴 하나… 명작이라고 하기엔…
[Review] 삼국군영전5
삼국군영전(이하 군영전) 시리즈는 새로운 것을 시도하기 보다는 기존의 것을 보완하는 방향으로 버젼을 거듭해 온 느낌이다.
Koei의 삼국지 시리즈가 커다른 틀에서 여러가지 다른 것들을 시도해 보는 것과는 반대된다.
군영전5 에서도 4에 비해서 특별히 달라진 것은 없다. 그렇지만, 개인적으로 4에서 가장 큰 불만사항 중에 하나였던, “적장의 자동 레벨업”이 아군에도 적용되어서 어느 정도 밸런스가 맞아들어간 느낌이다.
4에서는 전투에 사용하지 않고 가만히 내정만 하고 있는 장수의 레벨은 절대 오르지 않았다. 그렇지만, 적진영의 장수들은 시간만 지나면 자동으로 레벨업을 했으니… 상당히 괴로웠었다..
그렇지만 여전히 반복되는 천인전투는 지루하다는…-_-;
Yhcting's Blog 