커널 모드 API 기반 윈도 시스템

방준영의 이미지

minzkn님의 블로그(http://blog.kldp.org/node/view/1063)중에 흥미로운 내용이 있어서 여기서 토론을 해봤으면 합니다.

minzkn wrote:
개인적으로 이런 생각을 해봅니다.

새로운 Module을 제작하여

X컨소시엄에 만족하면서 System call을 통한 GUI를 만들어 보는것...

즉, X window시스템 같은 것이 Kernel의 module로 재 작성된다면 어떨까요?

Windows kernel의 GDI처럼 커널의 일부로 움직이는것...

System call을 0x81같은것으로 reserved하고

사용하는것이죠....


윈도 GDI처럼 커널의 일부로서 그래픽 API를 구현하는 것은 기술적인 측면으로나 유용성 측면에서 매우 가치가 있을 것이라고 생각합니다. 아마도 성공한다면 궁극적으로 윈도의 그래픽 카드 드라이버를 리눅스나 BSD같은 오픈 소스 OS에 그대로 가져와 사용하는 것이 가능해지겠죠. 그럼 항상 최신 드라이버 미지원 문제로 허덕이고 있는 이쪽 진영에 큰 힘이 될 수 있을 것이구요. 아직 시작하지는 않았지만(그리고 언제가 될지 확실친 않지만) 제 프로젝트("Moguawin")도 비슷한 방향을 목표로 하고 있습니다. 대략적인 단계는

- XFree86으로부터 네트워크 투명성 제거
- X11 API를 Win32 GDI32/User32 API로 대체
- 그래픽 드라이버 코드를 커널로 밀어 넣음
- 드라이버 API를 Win32 NtGdi/NtUser*() API로 대체
- 윈도 그래픽 드라이버를 리눅스/BSD에 로드하여 그대로 사용

정도로 예상하고 있습니다. 대체라고 되어 있는 부분은 목적에 따라 동시 지원하거나 양자 택일할 수 있도록 하면 되겠죠. Microwindows(microwindows.org)가 하는 것처럼요.

죠커의 이미지

mogua 프로젝트가 성공하길 기원합니다. :-)

maddie의 이미지

커널쪽은 잘 알지 못해 잘은 모르지만, perky님의 블로그에서 NDIS란거를 본적이 있는데 왠지 유사하다라는 생각이드는군요. 그건 네트웍카드쪽에서의 드라이버 호환이지만..

좀 오래된 글인데 답글이 별루없네요~

여러 리눅서들의 의견을 한번 내어 보시는게 어떨런지요..분명히 반응속도가 떨어지는 GUI는 xwindow의 단점이니깐요.

일전에 리누스 토발즈가 이런 의견에 대해 부정적인 예기를 했다는데 사실일까요?

힘없는자의 슬픔

pyrasis의 이미지

리눅스 커널은 리눅스 커널대로 개발되어 나왔고

X는 X대로 개발 되어 이 둘은 전혀 별개의 것이 되어 버려

지금은 이 둘을 붙이려 해도 십수년이 지난 소스들을

합치기는 상당히 어려울듯 합니다.

리누스 토발즈라는 사람 부터가 이런류의 방향에 회의적이기 때문에

가능성을 더 희박하게 하고 있죠.

xyhan의 이미지

예전에 X 윈도우 시스템을 커널쪽으로 통합하자.. 라는 의견이
있었던걸로 알고 있습니다.... 그 당시에는 시기 상조라 거부 당했지만..
이제는 데스크탑 리눅스의 미래를 위해서라도 조금은 서두를 필요성이
있다고 생각하고 있습니다..
개인적으로 X가 커널 쪽으로 통합된 배포본이 나오지 않는걸 이상하게 생각하고 있습니다...
기본을 X환경으로 하는 배포본은 많이 있는데
왜 X 윈도우즈가 커널쪽으로 들어가는 배포본은 없는지 말입니다..

왜 X 윈도우즈가 커널쪽으로 못들어가고 있는지 정말로 알고 십습니다...
개인적으론 커널이 너무 커진다... 정도 밖에는 생각 못하겠네요...?
모듈처럼 띄우는 거라면 ... 상관 없는 건가요.. -_- ..

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

선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-

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

oprix의 이미지

커널이라는게 탄탄해야 믿을만 한데, Xwindow 를 집어 넣을 경우

시스템이 불안정해지기 때문이라고 알고 있습니다.

제가 들은 바에 따르면, Windows NT 도 Cutler 아저씨가 Window 부분을 커널 바깥에 놓았는데. 이 후 속도가 나지 않아 커널 내부에 집어 넣었다는 얘기가 있습니다. 그 후 파란화면 후 시스템이 뻗는 상황이 많이 생겼답니다...

전지현 짱!

pynoos의 이미지

사실 현재의 X 가 가지고 있는 네트워크 추상층은 사실 불필요한 것 같습니다.
기껏 Unix domain socket 아니면 TCP/IP 수준으로 접속하는 것으로 알고 있구요.
Unix domain socket을 쓸 정도의 local 이면, 레이어를 줄이는 방향으로 바뀌는 것이 더 경쟁력이 있다고 보여집니다.

네트워크 추상층이 불필요하다라고 말한 이유는 이른바 XTI 계열의 추상층이 있어 Transport layer를 추상화하려했지만, 사실 Network은 TCP/IP로 통일돼 버려 거의 사용되지 않는 상황이지요.
따라서 X 서버와 클라이언트 개념도 이런 Transport Layer에 상관없이 GUI 환경을 추구하려고 Transport layer를 중간에 둔 모델이라 생각한다면, 딱 두벌만 있으면 될 것 같습니다.

이하 질문은 정말 궁금해서 하는 질문입니다.
제가 X windows쪽은 그다지 경험이 없어서... 질문이 많습니다.

Graphic Interface가 커널 레벨일 때의 이점은 커널 수준에서 그래픽 디바이스를 다루는 메시지가 나올 경우 커널/유저레벨 모드 변환 없이 화면에 반영되는 것이 가장 큰이점인가요? 아니면 X server와 Network Layer를 없애기 위한 것이 이점인가요? 아니면 둘다인가요?

Graphic Interface의 호출 동기가 주로 사람의 포인팅 디바이스에서 오는 것이 많을것 같은데 맞습니까? (포인팅 디바이스가 아니라면, 일반적인 어플리케이션 운영중에 발생하는 것이겠지요.)

전반적으로 메시지 전달시점부터 Graphic card에 어떤 변화를 주기까지의 short cut을 찾으려는 시도인데, 그런 시도는 결론이 항상 커널안에 포함되는 형태로 나는 것인가요? 아니면 다른 시도가 있었나요..?

궁금합니다.

정태영의 이미지

http://freedesktop.org/Software/xcb

이런것도 있습니다 =3=33

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

pyrasis의 이미지

단순히 X를 최적화해서 리눅스 커널에 집어 넣었다 하더라도 장기적으로 볼때 상황은 나아질게 하나도 없다는 것이죠.

이 논의의 가장 중요한 포인트는 바로 윈도우 그래픽 드라이버를 바로 사용할 수 있게 한다는 점과 Win32 API의 탑재입니다. 차후에는 완전한 윈도우 시스템으로 가는게 목표입니다.

이런 작업하기 위해서는 X의 네트웍 투명성을 제거하고 몸집을 줄이는 작업이 필요한 것이죠.

방준영의 이미지

pynoos wrote:
Graphic Interface가 커널 레벨일 때의 이점은 커널 수준에서 그래픽 디바이스를 다루는 메시지가 나올 경우 커널/유저레벨 모드 변환 없이 화면에 반영되는 것이 가장 큰이점인가요? 아니면 X server와 Network Layer를 없애기 위한 것이 이점인가요? 아니면 둘다인가요?

커널 수준에서 GUI를 구현하더라도 여전히 커널/사용자간 모드 전환은 필요합니다. 하지만 X와 달리 프로세스간 컨텍스트 전환이 필요하지 않다는 것이 큰 장점입니다. X는 메시지를 전송할 때 커널-서버-클라이언트간 잦은 모드 전환과 컨텍스트 전환이 발생하기 때문에 아무리 빨라도 윈도를 따라잡는 데 한계가 있습니다.

그렇지만 커널 모드 GUI 시스템이 꼭 성능만의 문제는 아닙니다. 요즘은 컴퓨터가 워낙 빨라져서 특별히 X가 느린 걸 체감하기 힘드니까요. 비단 성능뿐 아니라 시스템 자원의 효율적 이용, 경량화, 프로그래밍의 용이성 등을 커널 모드 구현의 장점으로 꼽을 수 있습니다. 당장 리눅스 프레임버퍼 드라이버만 보더라도 XFree86 비디오 드라이버보다 응용 프로그램에서 사용하기가 비교할 수 없이 쉽죠. 게다가 XFree86의 경우 커널이 이미 해놓은 하드웨어 탐지와 버스 스캔을 자기가 한번 더 할 뿐 아니라 모듈 로더도 별도로 구현을 하고 있는데, 커널과 연계하도록 구현했더라면 근본적으로 필요없었을 부분들입니다.

Quote:
Graphic Interface의 호출 동기가 주로 사람의 포인팅 디바이스에서 오는 것이 많을것 같은데 맞습니까? (포인팅 디바이스가 아니라면, 일반적인 어플리케이션 운영중에 발생하는 것이겠지요.)

예, 컴퓨터의 목적이라는 게 직접적이든 간접적이든 사람이 시킨 일을 하는 것이니까요.
방준영의 이미지

oprix wrote:
커널이라는게 탄탄해야 믿을만 한데, Xwindow 를 집어 넣을 경우

시스템이 불안정해지기 때문이라고 알고 있습니다.

제가 들은 바에 따르면, Windows NT 도 Cutler 아저씨가 Window 부분을 커널 바깥에 놓았는데. 이 후 속도가 나지 않아 커널 내부에 집어 넣었다는 얘기가 있습니다. 그 후 파란화면 후 시스템이 뻗는 상황이 많이 생겼답니다...


아무래도 커널 프로그래밍 자체의 제약이 있고, 커널에 생긴 문제를 디버그하기가 훨씬 힘든 점이 있습니다(조금만 잘못 되어도 시스템이 바로 죽으니까). 그런 의미에서 일단 원형은 사용자 모드에서 구현을 하고, 어느 정도 안정성이 입증되면 커널로 코드를 이전하는 것이 가장 이상적인 방향이라고 봅니다. 음.. 쓰고 보니 윈도가 바로 그런 방식이네요. 8)
pynoos의 이미지

GDI가 한번에 커널에 들어가는 것은 어렵다면,
curses 라이브러리정도부터 커널에 넣고 윈도우 개념을 발전시켜나가는 것은 어떨까요?
curses 를 재미 삼아 커널에 넣고 텍스트 기반에서 사용될 만한 X protocol 부터 차근차근 이동시켜가면... 재밌을것도 같습니다만..
curses에도 어줍잖은 윈도우 개념이 있고, 어느정도 위짓이라는 개념도 있으므로 흥미로울 것 같은데 말이죠..

Device Context라든지, 윈도우 계층구조, 그 구조에 의한 메시지 전달, 등등...

방준영의 이미지

pynoos wrote:
GDI가 한번에 커널에 들어가는 것은 어렵다면,
curses 라이브러리정도부터 커널에 넣고 윈도우 개념을 발전시켜나가는 것은 어떨까요?
curses 를 재미 삼아 커널에 넣고 텍스트 기반에서 사용될 만한 X protocol 부터 차근차근 이동시켜가면... 재밌을것도 같습니다만..
curses에도 어줍잖은 윈도우 개념이 있고, 어느정도 위짓이라는 개념도 있으므로 흥미로울 것 같은데 말이죠..

Device Context라든지, 윈도우 계층구조, 그 구조에 의한 메시지 전달, 등등...


curses같은 터미널 기반 API는 GUI의 목적과 배치된다고 봅니다. GUI라는 게 결국 터미널을 대체하기 위해서, 즉 curses같은 것을 안쓰기 위해서 만든 것이니까요. 8) 물론 기술적으로나 흥미 목적으로 구현은 가능하겠지요.
CY71의 이미지

장기적인 관점에서 보면, 궁극적으로는 커널과 XFree 의 통합을 의미하는 것 같군요.

문제는 오픈소스 진영에서는 각각의 프로젝트가 모두 따로 개발되고 있다는 겁니다. 커널 / XFree / Gnome / KDE / 각종 라이브러리 등이 모두 각각의 프로젝트에 의해 진행됩니다.

이런 상황하에서 양자를 통합하는 것은 솔직히 무리가 있다고 보입니다.

다콘의 이미지

CY71 wrote:
장기적인 관점에서 보면, 궁극적으로는 커널과 XFree 의 통합을 의미하는 것 같군요.

문제는 오픈소스 진영에서는 각각의 프로젝트가 모두 따로 개발되고 있다는 겁니다. 커널 / XFree / Gnome / KDE / 각종 라이브러리 등이 모두 각각의 프로젝트에 의해 진행됩니다.

이런 상황하에서 양자를 통합하는 것은 솔직히 무리가 있다고 보입니다.

기술의 발전은 무모해 보이는 것에 도전할때 이루어지기도 하는것이니 비관적으로만 볼건 아니라고 봅니다.

hey의 이미지

리눅스 커널에 넣는다는 것인가요?
다른 POSIX OS에서의 구현은 어떻게 할 수 있을까요?


----------------------------
May the F/OSS be with you..


cwryu의 이미지

X에 네트워크 투명성이 있다고 성능이 저하되는 건 아닙니다. 윈도우 터미널 서비스때문에 윈도우가 느려지나요? 그냥 투명성만 제거한다고 속도가 향상된다면야 벌써 그렇게 빨라진 X가 나왔겠죠.

문제가 있다면 그 투명성을 위해 옛날옛적에 만든 X 프로토콜이 너무 로우레벨이라는 것.. 복잡한 GUI에 이용하려면 수많은 X 콜을 해야 하기 때문에 문제이지 네트워크 투명성이 있다는 그 자체가 흠이 되진 않습니다.

말씀하시는 네트워크 투명성 제거도 이런 의도에서 하신 말씀이시겠지요? 노파심에서..

방준영의 이미지

cwryu wrote:
X에 네트워크 투명성이 있다고 성능이 저하되는 건 아닙니다. 윈도우 터미널 서비스때문에 윈도우가 느려지나요? 그냥 투명성만 제거한다고 속도가 향상된다면야 벌써 그렇게 빨라진 X가 나왔겠죠.

심각하게 저하되었고, 그런 X가 이미 나와 있습니다. 여기를 읽어보시죠: http://www.rocklyte.com/news.html

Quote:
문제가 있다면 그 투명성을 위해 옛날옛적에 만든 X 프로토콜이 너무 로우레벨이라는 것.. 복잡한 GUI에 이용하려면 수많은 X 콜을 해야 하기 때문에 문제이지 네트워크 투명성이 있다는 그 자체가 흠이 되진 않습니다.

X처럼 네트워크 투명성을 코어 차원에서 구현한다는 건 어리석은 생각입니다. 왜냐하면 훨씬 높은 차원에서 구현하더라도 원격 데스크탑은 얼마든지 가능하고, 더군다나 네트워크 투명성이 필요없는 대부분의 사용자들과 프로그래머에게 일부러 부담을 지울 필요가 없으니까요. 가령 X에서는 화면에 윈도우를 표시하거나 속성을 변경하는 함수가 성공적으로 리턴하더라도 실제로 그렇게 되었는지 보장이 안됩니다. 윈도우 안에 뭘 그리기 전에 확인을 해주어야 하죠. 이벤트가 비동기적이기 때문에 발생하는 여러 가지 문제도 있는데(반응속도 저하, 오동작, 프로그램하기 어려움), 전부 툴키트 제작자의 몫입니다. X는 프로그래머와 사용자를 모두 짜증나게 합니다.