Ting 이네 Software 이야기

회사에서 근무하는 개발자들 가운데, 개발 자체를 좋아하거나, 혹은 기술을 숙련시키는 과정의 한 방법으로 자체적으로 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를 회사에 공개하지 않을까... 조심스럽게 생각해 본다.

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...

그로우랜서 게임 리뷰를 하면서.. 갑자기... 그 동안 내가 즐겼던 게임들이 떠올랐다.
각각에 대해 리뷰를 쓸수는 없겠지만... 언급이라도 하고 싶어서... 이곳에 한꺼번에 적는다.
생각날때마다 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. 수작이긴 하나... 명작이라고 하기엔...

<출처를 기억할 수 없는 것은 생략했습니다. 혹시 문제가 되는 부분이 있다면 알려 주시기 바랍니다.>

• 좋은 코드는 변경하기 쉽고, 나쁜 코드는 변경하기 어렵다. 그러므로 좋은 코드는 나쁜 코드가 될 때까지 변경된다.
• “Provide mechanism not policy” : about interface design. (From the UNIX)
• 또 뭐가 있지??? --- 당장은 생각이 안나는 관계로...

There are two simple examples for this.

#ifdef A
#define xxx(...) BBBB(__VA_ARGS__)
#else
#define xxx(...)
#endif

vs.

#ifdef A
#define xxx(...) BBBB(__VA_ARGS__)
#else
static inline void xxx(){}
#endif

I preferred the second one because at the first case, sometimes unexpected problems are issued. (Just personal opinion/preference...)

[ g++ issue ]

g++-4.4 / g++-4.5 doesn't detect following case, but, g++-4.6 does.

< a.cpp >
---------

class P {
public:
    void a();
};

class A : public P {
public:
    void p();
};

void
P::a() {
    // 'const' quailifier' is discard here!
    static_cast<const A*>(this)->p();
}

void
A::p() {
    ;
}

int
main() {
    return 0;
}

=================== Test ======================
$ g++-4.5 a.cpp   <= OK.
$ g++-4.6 a.cpp
a.cpp: In member function ‘void P::a()’:
a.cpp:13:33: error: passing ‘const A’ as ‘this’ argument of ‘void A::p()’ discards qualifiers [-fpermissive]

The problem is some of Android codes still have above bugs in its code - ex. frameworks/base/libs/utils/RefBase.cpp.
So, even if Android source code was successfully compiled at g++-4.4 or g++4.5, it may be failed at g++-4.6 (for example, upgrading host OS)

[ cc/gcc issue ]

Compiling with gcc-4.6 raises following warings.

<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default]

In some component which uses '-Werror' option, this warning stops compilation.

[ Conclusion ]

So, you would better to use gcc/g++-4.4 instead of 4.6 when building Android, until above issues are resolved on Android baseline.
(ex. Ubuntu 11.10 as an Android host OS.)

내 생각에 대한민국은 '조언'의 문화보다는 '훈계'의 문화가 지배적인 것 같다.
'조언'의 문화란, 대등한 관계에서 이루어지는 '제안' 같은 것을 의미하고, '훈계'란 상하관계에서 가르침을 뜻한다.
대한민국에서 부모/자식 관계는 대등하기 보다는 상하관계에 가깝다.
따라서 부모는 자식을 '훈육'하게 되고, 자식입장에서는 가르침을 받게 된다.
'조언'이든 '훈계'든 어떤 것이 낫고 나쁜지는 모르겠다.

그런데 재미있는 것은 '훈계'의 문화에서 사용되는 '가르침'이  '질책'의 의미로 사용되는 경우다.
사실 상당히 많은 경우, 상하관계에서의 '훈계'는 '가르침'보다는 '질책'의 의미를 가진다. '사랑'이 바탕이 되는 부모/자식 관계도 그러할진데, 다른 사회적인 관계에서는 말할 필요도 없겠다. 그래서 그런지, 대한민국이란 나라에서 (다른 나라의 경우는 잘 모르겠다.), 사회적인 관계를 형성하는 사람들 사이에서는 '감사합니다.' 보다는 '죄송합니다.'가 더 익숙한 것 같다.

예를 들어, A 신입사원이 거래처와의 일을, 조금 어설프게 처리했고, 그래서 B대리는 A신입사원의 일처리에서 문제점들을 지적했다고 생각하자. 만약 A가 신입사원이 아니라 대리 혹은 과장이였다면, 위 사안은 '질책'이 될 가능성이 높다. 그렇지만, 신입사원이다. A가 일의 내용을 어설프게 처리할 것은 당연한 일이고, 아마 신입사원에게 맡긴 일이라면, 어느 정도의 실수는 용납될 일이 였을 것이다. 이런 경우, B대리가 A사원에게 하는 말은 '질책'처럼 들릴지라도 '훈계'에 가깝다. 그렇다면, A사원의 대답은 '죄송합니다.' 보다는 '감사합니다.'가 옳지 않을까?
'자신의 잘못된 부분을 지적해주고 가르쳐 주어서 감사합니다. '가 맡는 대답이 아닐까 말이다.
그렇지만, 우리들 대부분은 '죄송합니다.'가 먼저 튀어나온다. 자라온 환경에서 '훈계'보다는 '질책'을 받아왔던 탓이리라.
설사, '질책'이라 할지라도, '감사합니다.'는 여전히 유요한 반응이다.
'질책'했다는 자체가, 관심의 표현이고, 더 잘되라는 뜻이기 때문이다. 그렇지만, 우리는 어김없이 '죄송합니다.'가 나온다.

어찌보면, 문화가 만들어낸 것인 것도 같다. 그리고 사실, 이것이 '잘못되었다!'라고 말할 근거도 용기도 없다.
그렇지만, 내 개인적인 생각으로는 '죄송합니다.'보다는 '감사합니다.'가 듣기도 좋고, 한결 부드러운 것 같다. 아닌가?
'조언'이든 '훈계'든 아니면 그것이 '질책'이든, '죄송합니다.'보다는 '감사합니다.'가 먼저 생각나고 떠오를 수 있는 문화, 그런 문화는 과연 어떨까?

In SMP system, to save power, not all cpus are active if system is not heavy loaded.
But let's image this case.
System is not heavy loaded - only cpu0 is active, but at some moment IRQ is issued very often in short time.
In this case, some of issued IRQs may be abandoned.

Let's assume a IC does abnormal operation if issued interrupt is not handled by MPU and system status is like above.
Then, system works abnormally when it is not loaded, but system works well when it is loaded.
(This is opposite of usual case. Most case, system may do abnormal operation when it is loaded.)
default IRQ affinity is usually, masked for all cores - IRQ can be handled by any cpu.
And, more than one cpus are active when system is loaded. So, there is less chance for IRQ to be abandoned - these are several cpus to handle!

This case shows very interesting issues at system!