그런데 굳이 커널의 기본 설비가 아닌 별도의 패치를 적용해서 OpenBinder를
Android에 적용한 이유가 아직 가슴에 와닿지 않습니다.
-> 이유: 기본설비라고 할수 있는 IPC(Shared Memory, Semaphore, Message Queue)을
이용하여 개발시에 시스템에 구성되는 애플리케이션이 많아질수록 Complexity가 높아지게되고,
시스템에 문제발생시 Debugging이 엄청 어렵게 되기때문입니다.
또한, 각기 생성되는 리눅스 커널입장에서의 프로세스들에 대해 POSIX.1C Threads Extensions의
지원까지 는 힘들겠죠..(이와 함께 System Library , Java Framework에 대한 부분까지 구글의 작업이 수행되었답니다.)
단순히 어플리케이션 사이의 ipc라면 이미 dbus를 사용하고 있는 것 같고요,
특별히 커널 드라이버와 통신을 하려면 기존의 설비인 netlink나 connector같은걸
써도 될것 같아보이는데요.
--> 이유:
여기서 한가지 고심해보실 것은 아시다시피
어플리케이션은 여러개의 프로세스 또는 여러개의 쓰레드로 구현될수 있습니다.
d-BUS는 물론 P2P으로 IPC할수도 있지만, 태생시의 목적상 Systemwide messsage bus가 목적이 더큽니다.
그리고, d-BUS라는 것이 커널의 sysfs 및 ude, HAL등과 일종의 연동되어 시스템에 구성됩니다.
제가 설명드린 OpenBinder의 정의와 선택이유에 대해 PPT를 한번더 참고해주시구요,
위의 질의하신 IPC기능 OpenBinder에서 제공되는 기능중의 하나이며, 그 이상으로
Java Application의 Threading Model에서 OpenBinder가 Synchronization, Critical Section,
Transaction, Dead Lock, Lock/Unlock, Atomic Processing을 지원하는 최소한의 IPC기능을
Mobile/HandHeld Device에서 더 보강된 개념입니다. 이러한 OpenBinder의 제공기능들은
Component 기반의 System Level Framewrok이라 할수 있겠져..(이것의 장점은 설명안드릴께요...)
이외에 더 많은 심층적인 얘기를 해볼수 있겠지만, 사실 저도 지식 Share를 위한 무료 강의였기에
문의해주신 내용에 대해 이정도의 설명으로 궁금증을 해소해드릴수 있을것 같습니다.(여러가지사정상..^^)
발표내용에 대해 많은 관심에 다시 한번 감사드립니다.