커널 개발에 관심 있으신분?

태훈의 이미지

http://kldp.org/node/122058#comment-548325

고성능 ARM 아키텍처 타겟으로 운영체제 커널 개발을 하고 있습니다.

이제 커널의 기본 기능은 구현은 마무리 되어가는 단계라서 조만간 0.1 버전을 릴리즈하면서 코드를 오픈하려고 합니다.

밑바닥부터 새로 구현했기 때문에 GPL 라이센스를 채택하지 않아도 되지만, 제가 오픈소스를 좋아하기 때문에 그냥 오픈하고 싶습니다.

코드를 오픈하기 전에 우리나라에서 커널 개발에 관심있으신 분이 얼마나 되는지 사전 수요조사를 하고 싶습니다. 가능하면 프로젝트가 관심받고, 열의가 넘치고, 재밌게 진행 되었으면 하거든요.

현재 프로젝트 소스 트리는 다음과 같습니다.

.
`- src
   |-- Doxyfile
   |-- Makefile
   |-- Rules.mk
   |-- apps
   |   |-- Makefile
   |   |-- Rules.mk
   |   |-- app1
   |   |   |-- Makefile
   |   |   `-- main.c
   |   |-- app2
   |   |   |-- Makefile
   |   |   |-- main.c
   |   |   `-- sh.h
   |   |-- app3
   |   |   |-- Makefile
   |   |   `-- main.c
   |   |-- app4
   |   |   |-- Makefile
   |   |   `-- main.c
   |   |-- apps.lds
   |   |-- config.mk
   |   |-- include
   |   |   |-- list.h
   |   |   `-- stdio.h
   |   `-- lib
   |       |-- Makefile
   |       |-- console.c
   |       |-- end_mark.c
   |       |-- start.S
   |       |-- syscalls.c
   |       `-- vsprintf.c
   |-- arch
   |   `-- arm
   |       |-- Makefile
   |       |-- boot
   |       |   |-- Makefile
   |       |   |-- idt.c
   |       |   |-- init.c
   |       |   |-- mm_init.c
   |       |   `-- start.s
   |       |-- config.mk
   |       |-- excep.S
   |       |-- idt.c
   |       |-- init
   |       |   |-- Makefile
   |       |   `-- kernel_start.s
   |       |-- io.c
   |       |-- irq.c
   |       |-- kernel.lds
   |       |-- lib
   |       |   |-- Makefile
   |       |   |-- arm_lib.h
   |       |   |-- delay.c
   |       |   |-- err_msg.c
   |       |   |-- io-readsb.S
   |       |   |-- io-readsl.S
   |       |   |-- io-readsw.S
   |       |   |-- io-writesb.S
   |       |   |-- io-writesl.S
   |       |   `-- io-writesw.S
   |       |-- memory
   |       |   |-- Makefile
   |       |   `-- pagetable.c
   |       |-- merge.lds
   |       |-- syscall_tlb.S
   |       |-- task
   |       |   |-- Makefile
   |       |   |-- idle.c
   |       |   `-- task.c
   |       `-- timer.c
   |-- boot
   |   |-- Makefile
   |   |-- init.c
   |   |-- ksh.c
   |   `-- ksh.h
   |-- drivers
   |   |-- Makefile
   |   |-- core.c
   |   |-- eth_smc9118.c
   |   |-- eth_smc9118.h
   |   `-- serial_pl01.c
   |-- fs
   |   |-- Makefile
   |   |-- diskio.c
   |   |-- ff.c
   |   `-- file.c
   |-- include
   |   |-- apps.h
   |   |-- arch-arm
   |   |   |-- board.h
   |   |   |-- context.h
   |   |   |-- gic.h
   |   |   |-- io.h
   |   |   |-- platform.h
   |   |   |-- schedule.h
   |   |   |-- serial.h
   |   |   `-- system.h
   |   |-- config.h
   |   |-- delay.h
   |   |-- driver.h
   |   |-- file.h
   |   |-- fs
   |   |   |-- diskio.h
   |   |   |-- ff.h
   |   |   |-- ffconf.h
   |   |   `-- integer.h
   |   |-- idt.h
   |   |-- irq.h
   |   |-- list.h
   |   |-- memory.h
   |   |-- net
   |   |   |-- ether.h
   |   |   |-- icmp.h
   |   |   |-- inet.h
   |   |   |-- ip.h
   |   |   |-- ip_addr.h
   |   |   |-- mii.h
   |   |   |-- netif.h
   |   |   |-- opt.h
   |   |   |-- pbuf.h
   |   |   `-- udp.h
   |   |-- net.h
   |   |-- sema.h
   |   |-- stdio.h
   |   |-- task.h
   |   |-- timer.h
   |   `-- types.h
   |-- lib
   |   |-- Makefile
   |   |-- console.c
   |   `-- vsprintf.c
   |-- memory
   |   |-- Makefile
   |   |-- end_mark.c
   |   |-- exec.c
   |   |-- ioremap.c
   |   |-- memory.c
   |   `-- region.c
   |-- network
   |   |-- Makefile
   |   |-- arp.c
   |   |-- ether.c
   |   |-- icmp.c
   |   |-- inet.c
   |   |-- ip.c
   |   |-- net.c
   |   |-- netif.c
   |   |-- netrx.c
   |   |-- nettx.c
   |   |-- pbuf.c
   |   |-- tcp.c
   |   `-- udp.c
   `-- task
       |-- Makefile
       |-- scheduler.c
       |-- syscall.c
       `-- task_manager.c
 
26 directories, 132 files

프로젝트 목표는
- ELF, PE 실행파일 호환
- 리눅스 드라이버 호환 -> DAL(Driver Abstract Layer)
- 고성능/멀티코어 ARM 아키텍처 최적화
- 현존하는 최신 커널 기술 구현(ex> FlexSC)
* 분산 운영체제(DSM, DFS, Load balancing, Task migration) 기능 제공 -> 철학 "Everything is one!"
* 그냥 제가 쓰려고요. :) 게임도 하고, 코딩도 하고, 웹 서핑도 하고, 서버도 돌리고...

현재 구현된 기능은
- 멀티 태스킹(선점형)
- 유저모드 어플리케이션 실행
- TCP/IP 네트워킹
- 가상 메모리
- 메모리 파일시스템(FAT32)
- 페이지 단위 메모리 관리
- 요구 페이징
- 몇가지 시스템 콜(FlexSC로 전환 예정)
-> fork(), exec(), open(), read(), write(), close(), exit(), ioctl()
- 커널 태스크
- 세마포어
- 커널 라이브러리 약간
- etc...

이제 0.1 버전이라서 할일도 많고 갈길이 멉니다. 문제는 코드를 오픈했는데 관심도 없고 재미도 없어지면 차라리 혼자하는게 편합니다. 그래서, 사전에 관심도 조사를 해보고 싶네요.

태훈의 이미지

GPL 라이센스를 채택하게 되면 제가 리눅스 커널 코드에 많이 익숙해서 리눅스 커널 코드가 많이 도입될 것 같습니다.

Just do it!

gurugio의 이미지

정말 많이 만드셨네요.
제가 아는 개인 개발 커널중 가장 기능이 많은것 같습니다.

ARM쪽은 개발자가많으니까 오픈하시면 관심갖는 분들이 많을것 같습니다.
참여하시는 분은 없어도 꾸준히 관심갖고 보시는 분들이 많을것 같습니다.

태훈의 이미지

제가 좀 많이 하긴 했지만 팀원 한명 더 있습니다. 김명준군이라고 주로 메모리 파트를 담당했죠.

소수 정예...ㅎㅎ;;

Just do it!

jwstyle의 이미지

관심이 있기는 한데 지금은 업무에 체이고 있어서...

근데 소셜겜은 언제만들고? ㅋㅋㅋ

----------------------------
Let's Do It

태훈의 이미지

소셜게임은 우선 커널 일단락 하고요.

그때가서도 하고 싶으면 하는거죠. :)

Just do it!

태훈의 이미지

커널 구현 외적인 부분이 약간 걱정입니다.

지금까지 TRAC+SVN을 사용해 왔었는데, 나름 잘써오긴 했지만 이대로 오픈하기엔 민망하기도 해서 대세인 http://github.com 으로 넘어가야 하나 고민하고 있습니다. 같은 팀의 명준군이 git에 익숙하지 않아서 반발이 예상됩니다만;;;

홈페이지도 만들어야 하고, 파이썬으로 코딩 스타일 체크 스크립트도 만들어야 하고, 이름도 정해야 하고(아직까지 커널 이름도 없습니다;;)...

제가 다 해도 됩니다.

.
.
.

그림자 분신술은 어떻게 쓰는건가요?

Just do it!

rgbi3307의 이미지

이곳에서 태훈님의 글을 가끔씩 봤는데, 커널을 코딩하고 계셨군요.
소스 트리를 보니까 많은 작업을 하신듯 합니다.
저와도 같이 작업 했으면 합니다.
아실지 모르겠지만, 제가 운영하고 있는 커널연구회(www.kernel.bz)의
가산디지털단지 사무실을 7월달부터 사용할 수 있습니다.
컴퓨터 장비, 프리젠테이션 시설등을 모두 자유롭게 사용할 수 있구요.
지금 직장을 다니시고 계시다면,
주말에 나와서 서로 발표하고 공유하고 하면서 서로의 포부를 자유롭게 개진할 수 있습니다.

From:
*알지비 (메일: rgbi3307(at)nate.com)
*커널연구회(http://www.kernel.bz/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

태훈의 이미지

감사합니다. 오픈하게 되면 연락드리겠습니다. :)

Just do it!

태훈의 이미지

'apps' 디렉토리는 애교로 봐주세요. 아직 보조기억장치 드라이버 및 파일 시스템 구현이 덜되어서 임시로 들어간 디렉토리 입니다. :)

현재는 유저모드 어플리케이션 테스트를 위해서 어플리케이션 이미지가 커널 이미지와 같이 빌드되도록 해두었습니다.

가까운 시일이 삭제 될 디렉토리 입니다.

Just do it!

potatogim의 이미지

아직 부족한게 많아서 감히 엄두는 못내겠군요...;

Talk is cheap. Show me the code.

https://www.potatogim.net/

나빌레라의 이미지

책 써 주세요!!!

훌륭한 책이 나올것 같습니다!

----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라

태훈의 이미지

쓰고 싶기는 한데, 이미 나빌레라님께서 쓰신 책이 있어서 안팔릴것 같아요;;

Just do it!

나빌레라의 이미지

디렉토리 트리 리스트만 봐도,
제가 만든 것보다 백만배는 훌륭한 커널을 제작하셨네요!

그냥 개발 일지를 정리하는 기분으로 쓰셔도
명저가 한 권 탄생할 것 같습니다.

(사실.. 제가 읽고 싶어서 그래요....:)

----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라

lmk378의 이미지

워 두분이서 저정도 퀄리티의 오에스를 만드시다니... 대단하십니다.
처음부터 작성하신 건가요? 아니면 다른 오에스를 기반으로 작성하신건가요?

태훈의 이미지

처음부터 만들었습니다.

타 OS 코드를 가져다 쓰지는 않았지만, 막힐때마다 일부 참고는 했습니다. 리눅스 커널이 가장 많은 도움되었고, 그외에도 MINIX3 및 ARM 펌웨어 예제등이 많이 도움되었습니다.

Just do it!

shint의 이미지

ㅇ_ㅇ'''

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

익명 사용자의 이미지

10년뒤에 성지가 될지도 모를 글이네요 ^^
훌륭하십니다~ㅎ

hongwoo의 이미지

태훈님~~~ 멋지네요~~
관심 매우 매우 많습니다.

-----------------------------
in the real-time scheduler !

태훈의 이미지

이홍우님 맞으시죠? 반갑습니다~!! :) 잘지내시나요?

관심 가져주셔서 감사합니다.

Just do it!

bus710의 이미지


좋은 결과 보셔서 많이 배포되면 좋겠습니다...^^

life is only one time

태훈의 이미지

오픈소스로 전환하는 가장 큰 이유가 기존 커널 고수분들의 피드백을 받기 위함입니다. 그분들이 흥미를 가질만큼 깔끔하고 완성도 있게 코드를 정리하는 기간이 약간 필요합니다.

홈페이지도 심플하게 만들고요. (요즘 node.js에 재미붙여서 이걸로 만들까 고려중입니다.)

기존 오픈 소스 프로젝트 벤치마킹해서 프로젝트 진행 프로세스도 확립하겠습니다.

타겟 머신도 너무 특수한 머신이라서 바꿔야 할 것 같아요. 현재는 구하기도 힘든 ARM11MPcore 입니다. SMP 구현 때문에 이것으로 정했습니다. 그나마 구하기 쉬운 Cortex A9로 바꿔야겠습니다. 좀 있으면 출시될 Cortex A15를 바라보고 있습니다. SMP 기능은 구현은 해두었지만 아직 동작하지 않으며 현재 디버깅 중에 있습니다.

잠시만 기다려 주세요.:)

Just do it!

gurugio의 이미지

피드백은 받으실 수 있겠지만
아무래도 고수분들이 소스를 자세히 읽을 시간은 없으실테니
깊이있는 피드백은 받으시기 힘들수도 있을것 같습니다.
문서화를 최대한 한다면 좀더 많은 피드백을 받으실 수 있지 않을까요?

참고로 저는 워낙 코드가 허접해서 그런지 피드백을 받아본 적이 없습니다.
숙제 요청은 좀 받아봤습니다만.

태훈의 이미지

역시 문서화가 중요하군요.

조언 감사합니다. 문서화도 열심히 해야겠어요!

Just do it!

나빌레라의 이미지

문서화를 "책 수준"으로 해도
피드백이 전혀 없는 경우도 있습니다..

-_-

----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라

gurugio의 이미지

판매부수라는 매우 긍정적이면서 금전적인 피드백이 있자나요 ;-)

워낙 실력이 좋으셔서 상관없을 수도 있지만
문서화를 잘 해놓거나 책을 내거나하면 취업에 좋을것 같습니다.
저는 취업할때 진짜 실력보다 좀더 점수를 받았었습니다.

pastime의 이미지

전혀 없진 않았을 텐데요.. ^^;

태훈의 이미지

김남형님 여기서도 뵙는군요. 반갑습니다. :)

Just do it!

태훈의 이미지

hul~ -_-;;

Just do it!

sohn9086의 이미지

근데 커널 이름은 아직 없나요? :)

생산적인 댓글을 달자

oneday의 이미지

훔?

그럼 커널이름 공모전이나 하죠;;

태훈의 이미지

운영체제 이름 멋진걸로 지어주세요. 채택되신 분께는 기여자(공헌자) 목록에 넣어드립니다. :)

저와 명준군이 점수를 매겨서 가장 높은 점수를 받은 이름으로 정하겠습니다.

Just do it!

sohn9086의 이미지

이름 : 크누트 (Knut)

이유 : 올해 아쉽게 세상을 떠난 아기곰 크누트를 기리는 뜻에서. 마스코트 만들기도 쉬울 듯 해서.

http://ko.wikipedia.org/wiki/%ED%81%AC%EB%88%84%ED%8A%B8_(%EB%B6%81%EA%B7%B9%EA%B3%B0)

http://lizzwritesgood.files.wordpress.com/2011/03/knut.jpg?w=390&h=299

생산적인 댓글을 달자

myungjun의 이미지

결국 공모전까지...
역시 개발 하다 보면 자연스럽게 커널 이름이 생길거라는 것은 그냥 헛된 기대였나보네요^^;

나빌레라의 이미지

명태OS...

----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라

xyhan의 이미지

확정인듯...

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

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

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

snowall의 이미지

영문명칭은 한글자씩 따서 "MTOS"라고 하면 어떨까요.

피할 수 있을때 즐겨라! http://melotopia.net/b

feanor의 이미지

Multi-Tasking Operating System?

태훈의 이미지

맘에 드는데 도메인이 없네요.

Just do it!

snowall의 이미지

mtos.kr 같은 도메인을 쓰시면 되지 않을까요?

피할 수 있을때 즐겨라! http://melotopia.net/b

hiseob의 이미지

생태커널 동태커널 등등등...???

snowall의 이미지

동태커널은 freeze버전인가요ㅋㅋㅋ

중간에 노가리 커널도...(alpha빌드?)

피할 수 있을때 즐겨라! http://melotopia.net/b

jeongheumjo의 이미지

캐나다의 QNX Software Systems 에서 만든 QNX 라는 RTOS 가 있습니다.
원래는 Qunix 였다고 합니다. .... Quick UNIX 를 줄여서
그런데 그게 등록된 상표였다고 합니다.
그래서 QNX(Qunix 에서 모음 삭제) 로 정해졌습니다. 읽을 때는 그래서 Qunix 와 같이 읽어요.(큐닉스)
RTOS 이면서(Quick, 누군가로부터 딴지 들어오는 소리가 들리지만...) UNIX like 하다는 것을 잘 알수 있도록 한 네이밍 인 것 같습니다.

만드신 OS도 어떤 특징이 있느냐에 따라 이름을 정해야 하지 않을까요? OS 계를 평정하려고 한다면, Conqueror 모음삭제 하면 CNQRR ?? 이상하군요.. ^^

익명 사용자의 이미지

보통 상대방에게 어떤 의사를 전달할때는..

상대방이 이미 알고있지 않은지 생각해봐야 하는 경우가 있는것 같은데요..

이번 경우가 그러한 경우에 속하는것 같습니다.

때로.. "~가 있습니다" 라는 형식으로 알려줄때 , 무례하게 보여지는 경우가 있다고 생각하거든요

제가 말꼬리를 잡고 늘어지는건진 모르겠으나..

그리고 태훈님 정도시면 이미 QNX 를 알고계실것같네요..

제가 느낀것과 다르게 좋은 의도로 말씀하신거겠지만..

자신이 알고있는것을 말하는것과,, 상대방이 필요로 하는 정보를 말하는것 2가지 경우에서..

자신이 알고있는 것을 그냥 말하는것은 , 게다가 만약 상대방이 그걸 알고 있을수도 있는 경우에서..

제가 보기엔 별로 좋아보이지 않아 이런글을 적게되었습니다.

그리고 제 닉네임은 jw8704 입니다.(로그인을 안해서)

jeongheumjo의 이미지

QNX 를 알고 있는 사람은 많겠지만 그 이름의 유래까지 알고 있는 사람은 별로 없을 거라는 생각에서 그 이름 명명의 유래를 설명했던 것입니다.
그 내용이 그렇게 많이 알려져있는지는 몰랐네요..

다른 사람 다 아는 얘기하는게 무례하다 하시면 저는 여기서 글을 못쓰겠는걸요..? 특히 이 쓰레드 같은 경우 다들 화려한 필력을 가진 분들이니까요..
저는 타의로 ROM족이 되는 케이스가 될 것 같네요.. 제가 정말 글쓰기를 참게 된다면요.. 아..

저는 'RTOS란 빠른 OS 를 의미하지 않는다'라는 정도의 반박글이 올까 걱정했는데 이런 글은 전혀 예상하지 못했네요..

익명 사용자의 이미지

아 , 그러셨군요...

jeongheumjo 님의 글을 읽고 나니까,, 제가 좀 비뚤어진 생각으로 바라봤다는 생각이 드네요..

말을 쉽게하면 안된다고 생각하는데.. 제가 성급히 행동했던것 같습니다.

앞으로 좀더 신중하게 행동하는 계기가 되도록 할게요..

진심으로 죄송합니다.

jw8704

태훈의 이미지

저는 뭔가를 구현하는데는 익숙하지만, 지식은 필요할때 찾아보는 타입이라서 많은 것을 알진 못합니다.

아직 많이 배워야 하는 입장이라서 많은 가르침이 필요합니다. :)

Just do it!

semmal의 이미지

OONDOW, OONIX, OONUX

윈도우, 유닉스, 리눅스에서 태훈의 Taeh"oon"과 명준의 MyeongJ"oon"을 따봤습니다.

너무 카피같다면,

그냥

OON

도 나쁘지 않다고 봐요.

운이라는 뜻에는 옮김, 행운, 운명, 운치, 이름, 구름 이라는 여러 뜻이 있죠.

맘에 드는 걸 골라서 쓰거나 모두 쓸 수도 있다고 봐요.

------------------------------
How many legs does a dog have?

익명 사용자의 이미지

여태 만드시느라 고생많이 하셨겟네요,,
소스트리 보니 정말 많이 고생하셨겠네요.
플래시메모리관련 or 저장장치 부분으로 참여하고 싶은데 얼마나 가능할지 의문요 ;;

관심있게 지켜보겠습니다.

사진보니 안면있는 태훈님 인거 같은데, 반갑네요^^

태훈의 이미지

하시는 분야만 봐도 누구신지 대충 감이 잡힙니다. :)

반갑습니다. :)

Just do it!

익명 사용자의 이미지

> 분산 운영체제(DSM, DFS, Load balancing, Task migration) 기능 제공 -> 철학 "Everything is one!"

eTiMo = Everything is One + Tae + Myeong
(Etimology(Etymology) : 어원)

OS의 원류가 되겠다는 중의적 의미

==> eTiMos 혹은 eTiMox

익명 사용자의 이미지

Neraso
Oraso

so를 뒤집은 다음 나머진 한글로 음역한다음 뒤집어서 읽어보세요.

구글링해보니 oraso는 여러 의미로 많이 쓰더라고요. 개인적으론 좀 거만한(...) Neraso 추천

pastime의 이미지

그런데 POSIX 호환성을 염두에 두고 계신가요?

태훈의 이미지

처음 기획때는 거창하게 POSIX 호환을 하자고 했지만, 만들다보니 처음부터 다 만드는거면 구지 POSIX 호환이 필요 없더라구요.

하지만, 오픈소스 라이브러리를 올릴려면 POSIX 호환이 지원되어야 할 것 같네요.

최소한 C 라이브러리와 컴파일러 정도는 올려야죠. (gcc, llvm, tcc 뭐가 되었든간에...)

Just do it!

익명 사용자의 이미지

프로그래밍을 좋아하는 4학년 1학기 학생인데요...
저도 오픈소스에 관심이 많긴한데 저같은 애송이가 보기에는 어렵고 대단하게만 보이네요
리눅스 설치하고 기본적인 부분은 책으로 공부해서 대충은 알고 있는데, OS만들어보는게 꿈이라서 마지막 방학을 맞이해서 공부해보려고 하고 있습니다.
학교 도서관에서 리눅스에 관련된 쉘 프로그래밍 하고 커널 관련 서적하고 GCC프로그래밍 3가지정도 볼려고 하는데
조언좀 부탁드립니다. ^^

태훈의 이미지

학생이시면 저희가 만든 커널을 한번 분석해 보시는 것도 도움이 되실겁니다.

설계 철학 때문에 몇가지 C 기법이 들어가긴 했지만, 최대한 심플한 구조를 유지하려고 노력했습니다. 리눅스 커널과 같은 다른 범용 운영체제 커널보다는 분석하기가 훨씬 수월 하실겁니다.

Just do it!

spkpc의 이미지

감사합니다. 대단히 기대되는군요.. 그런데
초보자가 보기에 커널의 구조를 쉽게 파악할 수 있는 책 있을까요?

그리고 C기법이란것이 ANSI, mini C를 말씀하시는건가요?

그렇다면 잘 됬네요.. 자신있는게 C언어 밖에 없어서리..

태훈의 이미지

기법이라는게 별건 아니고, 아래 코드만 이해 하실 정도면 됩니다. 대부분의 커널 모듈이 구조체의 함수 포인터를 활용하는 형태로 되어 있습니다. (리눅스 커널의 VFS 처럼...)

/**
 * @brief 스케쥴러 모듈.
 */
struct scheduler scheduler = {
    .init = scheduler_init,
    .schedule = schedule,
    .start = scheduler_start,
    .add = task_add,
    .del = task_del,
    .get_list = rq_list,
};

Just do it!

김성진의 이미지

어디에서 일하시는 분인지 모르겠지만, 간만에 기대를 품게 합니다.

소스 공개하시면 GPL도 좋지만, BSD 와 같은 타인의 상용화의 길도 같이 열어 놓으시는게 어떨지요?

한번 뵙고 싶군요.

알티베이스 김성진 드림

고도의 추상화, 극도의 구체화, 에디슨을 그리워하다.

태훈의 이미지

관심가져주셔서 감사합니다. :)

결과물 보호를 위해서 BSD는 라이센스는 고려하고 있지 않습니다. Closed Code도 지원하도록 다른 라이센스도 알아보도록 하겠습니다.

ps. 백수입니다.

Just do it!

익명 사용자의 이미지

1. GPL은 상용화의 길을 막나요?
2. 알티베이스사는 BSD나 MIT 라이센스에 준하는 수준의 공개 방침을 두고 있나요?

김성진의 이미지

리처드 스톨만의 선언을 읽어보면 GPL이 상용화를 막거나, 개발자에 대한 이윤 추구를 금지하고 있지는 않습니다.
GPL로도 상업화는 가능하지요. 그러나 현실로 돌아와보면 GPL자체를 통해 이윤 추구를 할 수 있는
방법은 서비스를 통해 부가가치를 창출하는 것이고, 저작물 그 자체를 판매하는 사례는
그렇게 많지는 않더군요. (없다는 게 아니구요)

알티베이스에서는 BSD나 MIT사례보다는 Freeware로 모니터링 툴을 오픈한 적이 있고,
서버 엔진 자체에 대해서는 오픈 소스와 관련된 앞으로의 계획은 없습니다.

고도의 추상화, 극도의 구체화, 에디슨을 그리워하다.

sjpark의 이미지

저도 만들고 있었는데,.
전 혼자서 하다 보니 버그도 많고,. 정리가 되지 않은 부분도 많습니다 ;)

저도 처음엔 ELF 와 COFF 를 동시에(?) 지원하는 커널을 만드려고 했었는데요,.
하다보니 생각이 조금씩 바뀌더군요 ^^

POSIX 표준을 따라서 만들려고 하다 보니,. 할 것들이 너무 너무 많아진데다가
회사 업무도 중요한지라.. 속도가 매우 느리게 나가고 있네요.. :(

이 포스팅을 보니 다시한 번 힘이 나네요.

제 OS 이름은 NCOS 입니다. ㅎㅎㅎ

.
├── Makefile
├── Makefile.common
├── a
├── arch
│   ├── Makefile
│   ├── common
│   │   ├── Makefile
│   │   ├── include
│   │   │   ├── block_io.h
│   │   │   ├── char_io.h
│   │   │   ├── memory.h
│   │   │   └── port.h
│   │   └── src
│   │   ├── common.c
│   │   └── memory.c
│   └── x86
│   ├── Makefile
│   ├── boot
│   │   ├── Makefile
│   │   └── boot.s
│   ├── drivers
│   │   ├── Makefile
│   │   ├── block
│   │   │   ├── Makefile
│   │   │   ├── fdc
│   │   │   │   ├── Makefile
│   │   │   │   ├── include
│   │   │   │   │   └── fdc.h
│   │   │   │   └── src
│   │   │   │   └── fdc.c
│   │   │   ├── ide
│   │   │   │   ├── Makefile
│   │   │   │   ├── include
│   │   │   │   │   └── 82371SB.h
│   │   │   │   └── src
│   │   │   │   └── 82371SB.c
│   │   │   └── part
│   │   │   ├── Makefile
│   │   │   ├── include
│   │   │   │   └── part.h
│   │   │   └── src
│   │   │   └── part.c
│   │   └── char
│   │   ├── Makefile
│   │   ├── console
│   │   │   ├── Makefile
│   │   │   ├── include
│   │   │   │   └── console.h
│   │   │   └── src
│   │   │   └── console.c
│   │   └── keyboard
│   │   ├── Makefile
│   │   ├── include
│   │   │   └── keyboard.h
│   │   └── src
│   │   └── keyboard.c
│   ├── kernel
│   │   ├── Makefile
│   │   ├── include
│   │   │   ├── arch.h
│   │   │   ├── dma.h
│   │   │   ├── entry.h
│   │   │   ├── gdt.h
│   │   │   ├── idt.h
│   │   │   ├── isr.h
│   │   │   ├── isr_service.h
│   │   │   ├── lock.h
│   │   │   ├── mrd.h
│   │   │   ├── pic.h
│   │   │   ├── tss.h
│   │   │   ├── video.h
│   │   │   └── x86vm.h
│   │   └── src
│   │   ├── arch.c
│   │   ├── dma.c
│   │   ├── entry.s
│   │   ├── gdt.c
│   │   ├── idt.c
│   │   ├── isr.c
│   │   ├── isr_entry.s
│   │   ├── lock.c
│   │   ├── mrd.c
│   │   ├── pic.c
│   │   ├── port.c
│   │   ├── start.c
│   │   ├── tss.c
│   │   ├── video.c
│   │   └── x86vm.c
│   ├── ncloader.ld
│   └── pci
│   ├── Makefile
│   ├── include
│   │   └── pci.h
│   └── src
│   └── pci.c
├── bochsout.txt
├── bochsrc.mine
├── bocshrc.old
├── common
│   ├── Makefile
│   ├── include
│   │   ├── debug.h
│   │   ├── errno-base.h
│   │   ├── errno.h
│   │   ├── for_user.h
│   │   ├── for_user.h.orig
│   │   ├── for_user.h.rej
│   │   ├── kmp.h
│   │   ├── list.h
│   │   ├── ncloader.h
│   │   ├── pool.h
│   │   ├── rbtree.h
│   │   ├── resource_str.h
│   │   ├── stack.h
│   │   └── tree.h
│   └── src
│   ├── debug.c
│   ├── kmp.c
│   ├── pool.c
│   ├── rbtree.c
│   ├── resource_str.c
│   ├── stack.c
│   └── tree.c
├── debuggerout.txt
├── deprecated
├── kernel
│   ├── Makefile
│   ├── binfmt
│   │   ├── Makefile
│   │   ├── coff
│   │   │   ├── Makefile
│   │   │   ├── include
│   │   │   │   ├── data_directory.h
│   │   │   │   ├── dos_header.h
│   │   │   │   ├── export_descriptor.h
│   │   │   │   ├── extra_pe32p.h
│   │   │   │   ├── header.h
│   │   │   │   ├── import_by_name.h
│   │   │   │   ├── import_descriptor.h
│   │   │   │   ├── optional_header.h
│   │   │   │   ├── relocation.h
│   │   │   │   ├── section_table.h
│   │   │   │   ├── string_table.h
│   │   │   │   └── symbol_table.h
│   │   │   └── src
│   │   │   ├── data_directory.c
│   │   │   ├── dos_header.c
│   │   │   ├── export_descriptor.c
│   │   │   ├── extra_pe32p.c
│   │   │   ├── header.c
│   │   │   ├── import_by_name.c
│   │   │   ├── import_descriptor.c
│   │   │   ├── optional_header.c
│   │   │   ├── relocation.c
│   │   │   ├── section_table.c
│   │   │   ├── string_table.c
│   │   │   └── symbol_table.c
│   │   └── elf
│   │   ├── Makefile
│   │   ├── include
│   │   │   └── elf_loader.h
│   │   └── src
│   │   └── elf_loader.c
│   ├── core
│   │   ├── Makefile
│   │   ├── include
│   │   │   ├── bottom_half.h
│   │   │   ├── buddy.h
│   │   │   ├── elf_loader.h
│   │   │   ├── internal_pmm.h
│   │   │   ├── kmalloc.h
│   │   │   ├── module.h
│   │   │   ├── page_cache.h
│   │   │   ├── page_frame.h
│   │   │   ├── pmm.h
│   │   │   ├── sched.h
│   │   │   ├── slab.h
│   │   │   ├── softirq.h
│   │   │   ├── syscall.h
│   │   │   ├── tasklet.h
│   │   │   ├── thread.h
│   │   │   ├── vm.h
│   │   │   ├── workqueue.h
│   │   │   └── zone.h
│   │   └── src
│   │   ├── bottom_half.c
│   │   ├── buddy.c
│   │   ├── internal_pmm.c
│   │   ├── kmalloc.c
│   │   ├── module.c
│   │   ├── ncloader.c
│   │   ├── page_cache.c
│   │   ├── page_frame.c
│   │   ├── pmm.c
│   │   ├── sched.c
│   │   ├── slab.c
│   │   ├── softirq.c
│   │   ├── syscall.c
│   │   ├── tasklet.c
│   │   ├── thread.c
│   │   ├── vm.c
│   │   ├── workqueue.c
│   │   └── zone.c
│   ├── fs
│   │   ├── Makefile
│   │   ├── device
│   │   │   ├── Makefile
│   │   │   ├── include
│   │   │   │   └── device.h
│   │   │   └── src
│   │   │   └── device.c
│   │   ├── fat
│   │   │   ├── Makefile
│   │   │   ├── include
│   │   │   │   └── fat.h
│   │   │   └── src
│   │   │   └── fat.c
│   │   ├── mem
│   │   │   ├── Makefile
│   │   │   ├── include
│   │   │   │   └── mem.h
│   │   │   └── src
│   │   │   └── mem.c
│   │   └── sys
│   │   ├── Makefile
│   │   ├── include
│   │   │   └── sys.h
│   │   └── src
│   │   └── sys.c
│   └── vfs
│   ├── Makefile
│   ├── include
│   │   ├── file.h
│   │   ├── inode.h
│   │   └── superblock.h
│   └── src
│   ├── file.c
│   ├── inode.c
│   └── superblock.c
├── keyboard.patch
├── lib
│   ├── Makefile
│   ├── include
│   │   ├── libc.h
│   │   └── stdarg.h
│   └── src
│   └── libc.c
├── list
├── ncloader.sln
├── ncloader.suo
├── ncloader.vcproj
├── ncloader.vcproj.NCWIN-NB.nicesj.park.user
├── ncos.vdisk
├── old
│   ├── kthread.c
│   ├── kthread.h
│   ├── task.c
│   └── task.h
├── parport.out
├── tags
├── test
│   ├── Makefile
│   ├── buddy.c
│   ├── internal_pmm.c
│   ├── kmalloc.c
│   ├── libc.c
│   ├── main.c
│   ├── module
│   │   ├── module
│   │   ├── module_a.c
│   │   ├── module_b.c
│   │   ├── module_init.c
│   │   └── replace.c
│   ├── slab.c
│   ├── vm.c
│   └── zone.c
├── tools
│   ├── Makefile
│   ├── conf.sh
│   ├── create_vdisk.sh
│   ├── disk
│   ├── disk.c
│   ├── dump_bootsector.c
│   ├── dump_hex.c
│   ├── functions.sh
│   ├── lba2chs.c
│   ├── pattern.c
│   ├── program
│   ├── program.c
│   ├── update_kernel.sh
│   ├── update_loader.sh
│   └── write.c
└── userspace
├── Makefile
├── app
│   ├── Makefile
│   └── test.c
├── crt
│   ├── Makefile
│   ├── include
│   │   └── crt1.h
│   └── src
│   └── crt1.c
└── libc
├── Makefile
├── include
│   ├── assert.h
│   ├── complex.h
│   ├── ctype.h
│   ├── dirent.h
│   ├── errno.h
│   ├── fcntl.h
│   ├── fenv.h
│   ├── float.h
│   ├── for_user.h -> ../../../common/include/for_user.h
│   ├── inttypes.h
│   ├── iobuf.h
│   ├── iso646.h
│   ├── limits.h
│   ├── locale.h
│   ├── math.h
│   ├── setjmp.h
│   ├── signal.h
│   ├── stat.h
│   ├── stdarg.h
│   ├── stdbool.h
│   ├── stddef.h
│   ├── stdint.h
│   ├── stdio.h
│   ├── stdlib.h
│   ├── string.h
│   ├── syscall.h
│   ├── tgmath.h
│   ├── time.h
│   ├── unistd.h
│   ├── waitpid.h
│   ├── wchar.h
│   └── wctype.h
└── src
├── clearerr.c
├── close.c
├── dirent.c
├── exit.c
├── fclose.c
├── feof.c
├── fflush.c
├── fopen.c
├── fread.c
├── freopen.c
├── fseek.c
├── fsetpos.c
├── ftell.c
├── fwrite.c
├── iobuf.c
├── malloc.c
├── open.c
├── printf.c
├── putc.c
├── remove.c
├── rename.c
├── rewind.c
├── scanf.c
├── setbuf.c
├── setvbuf.c
├── stdlib.c
├── string.c
├── syscall.c
├── tmpfile.c
├── unistd.c
└── waitpid.c

76 directories, 294 files
(여기서 실제 코드가 있는 파일은 50% 정도입니다. ^^;, 빈파일이 대부분)

지금까지 boot loader 와 kernel, libc 가 하나의 프로젝트 안에서 구현하고 넣고 했었는데,.
S/W architecture design 자체에 심각한 문제를 발견해서 각각을 분리한 후 설계를 보강해서 다시 살펴 볼 계획입니다.

filesystem은 FAT12(16) 이고 Read 만 가능하구요
memory 관리는 buddy 와 slab(coloring등 고급 기능 제외 기본 기능만)에 pmm이라는 아주 단순한 형태의 memory allocator를 쓰고 있구요
지원 architecture 는 x86 입니다. (cache manager 는 없습니다.;;)

base storage 는 Floppy disk 이고
지원 binfmt 는 ELF 이구요
COFF 폴더가 있는데 전부 빈 파일입니다. COFF는 userlevel 용 테스트 어플리케이션으로 스펙에 맞춰서 구현한것이 있는데
그걸 저기에 넣을 계획이구요

kernel thread 와 task 관리까지 구현했구요

userapp 으로는 간단한 shell 하나밖에 없네요..
버그가 있어서 fork 한 10번 하면 메모리 full 로 뻗습니다. ㅡㅜ 잡아야 하는데..

libc 부분에서도 빈파일이 90% 고 10% fopen/fread/fwrite/fclose등과 readdir/opendir/fork/waitpid/scanf/printf/exit등 몇가지 작업진행에 필요한 primitive api 들만 구현된 상태구요.

현재는 x86기반이지만 arm 도 포함시킬 계획인데요.
괜찮으시면 앞으로도 꾸준히 정보 공유를 할 수 있었으면 합니다. ^^

앞으로 계획은 회사 업무에 영향을 끼치 않는 범위내에서.. 체력이 받쳐 주는한 =0=
boot loader 와 kernel, libc 프로젝트를 분리 시키고, 올해 또는 내년안에 1.0 version 을 release 하고
그 후에 compiler 와 libc를 보강해나갈 계획입니다.

kernel은 ELF 포맷으로 전환해서(현재는 flat binary) module loading 이 가능한 구조가 되도록 하고
boot loader 에서는 kernel 을 압축된 상태로 (지금 리눅스 커널이 오래전부터 해오던거 처럼) 로딩해서
online uncompressing 을 해서 로딩하게 하는겁니다.

그런데 막상 boot loader 부터 architecture 와 filesystem, storage type 에 independent 하게 만드려고 생각하니
이거 자체많으로도 혼자하기엔 엄청난 프로젝트네요 -_-

제가 알기로는 이미 OS 개발을 마치신 국내 개발자 분들도 많으신거 같더라구요.
어떤분은 32bit 마치고 64bit 까지 진행하신분들도 있었구요. 그분들 블로그에서 눈팅만 열심히 하다가 좌절하곤 했죠..ㅋ
취미로 하기엔 열정이 점점 식어가고 있네요..ㅜㅠ

전 수원에서 지내고 있구요.
괜찮으시면 정보 공유도 할 수 있었으면 합니다.

아래 링크는 동영상 링크에요...
http://www.youtube.com/watch?feature=player_embedded&v=NIulGgbO0D0

태훈의 이미지

저희 커널보다 훨씬 많이 진행 하셨네요.

해보셔서 아시겠지만 아키텍처 관련된 작업이 상당 부분 차지하기 때문에 타겟을 High-end ARM으로 한정 지었습니다. x86의 기존 운영체제 따라 잡을 자신도 없구요.

물론, 그렇다할지라도 최대한 아키텍처 독립적으로 개발하고 있습니다.

코드 트리 보고 이미 개발 완료 하신줄 알고 순간 놀랐습니다;;

Just do it!

태훈의 이미지

:)

Just do it!

sjpark의 이미지

사실 x86 는 PCI 버스나 뭐 관련 스펙들은 현업에선 전혀 도움이 안되죠
S/W 부분이면 몰라도...

ARM을 선택하신건 현업에서도 큰 도움이 되실것 같아요..

동영상 보셔도 아시겠지만..
이로 치면 잇몸도 제대로 안된상태랍니다 :)

태훈의 이미지

사실 TCP/IP 스택 구현은 TCP/IP 프로토콜에 대해서 잘 알고 있으면 쉬운 편입니다.

그런데, 네트워크 칩 드라이버를 구현하는게 일이 좀 많더군요. 제가 리눅스 네트워크 드라이버 개발 경험이 좀 있어서 그나마 쉽게 구현했습니다.

x86에서 네트워크 드라이버를 개발하려고 하면 토 나올듯 합니다;;

Just do it!

익명 사용자의 이미지

x86라서 특별히 어려운 이유가 뭐가 있으려나요?

태훈의 이미지

복잡한 BUS interface 때문 입니다. ARM은 직관적인 Memory Mapped I/O로 디바이스를 제어 할 수 있거든요.

뭐 그것도 한번 해보면 쉬울지 모르지만 아직까지 경험이 없어서요.

Just do it!

익명 사용자의 이미지

x86과는 관련없습니다. x86에서라도 어차피 pci장치들의 mapping만 끝내주고 나면 memory mapped I/O 처럼 사용하므로 사실 드라이버 작성 자체에는 차이가 거의 없다고 봐야합니다. 사실 이것은 ARM이라도 PCI controller를 붙이게 된다면 똑같은 방법으로 처리해야 합니다.

태훈의 이미지

x86 아키텍처로 만든 타겟 머신과 ARM 아키텍처로 만든 타겟 머신이 어떤 버스 인터페이스를 사용하느냐에 따라서 달라지겠죠.

제가 가장 잘아는 아키텍처는 x86 입니다만, x86 아키텍처에서 펌웨어 레벨 디바이스 제어하는 것을 해 본 적이 없습니다. '어려워서 그렇다.'라는 건 아니고, '하기가 까다롭다.' 정도 인 것 같네요.

x86 아키텍처는 호환성을 고려한 설계 때문에 난잡한 구조로 되어 있어서 그다지 좋아하지 않습니다. 개인적으로는 호환성은 개뿔, 그딴거 다 쓰레기통에 처넣고 64 bit mode만 지원하도록 하였으면 좋겠습니다. (죄송합니다;; 커널 개발자 입장이라서요.)

ARM은 펌웨어 레벨(하다못해 어셈 레벨에서도)에서도 디바이스 제어하는데 아무런 거리낌이 없었습니다. 아키텍처 구조도 심플하고 직관적이라 마음에 듭니다.

"Simple is best!"

Just do it!

익명 사용자의 이미지

정말 이해하고 싶어서 그러는데 예를 약간 들어주실수 있나요?

다양한 아키텍쳐를 접해봤지만 아키텍쳐의 차이가 펌웨어 레벨, 디바이스를 제어하는데에 과연 무슨 차이가 있는지 궁금합니다.

그 "까다로움"이 뭘까 궁금합니다.

드라이버를 제어하는데 아키텍쳐의 특성을 타는 bootloader 혹은 OS라면 shim layer를 좀 더 보강해야 하는 구조가 아닐까 싶습니다.

태훈의 이미지

경험에 의한 지극히 개인적인 의견이라서 너무 깊게 생각하지 않으셔도 됩니다. 제가 펌웨어 레벨에서 PCI 버스 인터페이스 구현을 안해봐서 그런것 입니다. :) (리눅스 커널에서 제공하는 API를 사용해서 리눅스 PCI 드라이버는 해봤습니다.)

기존 OS 커널상에서 드라이버를 개발하면 커널에서 제공해주는 함수만 사용하면 되지만, 커널을 새로 만드는 입장에서는 각 버스 인터페이스를 모두 구현해야 합니다. 이제 0.1 버전이라서 아직 그정도까지는 구현되어 있지 않습니다.

드라이버 제어에 아키텍처 특성에 유연하도록 구현하였지만, 아직 버스 인터페이스에 유연할 정도로 구현되어 있지는 않습니다. 앞으로 차차 개선해 나가야죠.

다양한 아키텍처를 접해보셧다니 어떠한 아키텍처를 접해보셨는지 알려주시면 좀 더 도움이 될것 같습니다. 저는 경험이 일천하여 x86, ARM, AVR, 8051, ppc 정도 밖에 못해봤습니다. (ppc는 약간만;;)

피드백 주셔서 감사합니다만, 고견을 주시는 분이 어떤 분이신지 알려 주실수 있으신가요? 요즘에 코드 한줄도 못쓰는 실력도 없으면서 입만 살아있는 분들을 많이봐서 그 분이 작성한 코드를 보기 전에는 100% 신뢰하지 않거든요. :)

단순히 깔려는 의도가 아니시고 순수하게 피드백을 주시는 의도이시면 어떠한 의견도 받아 드릴테니 본인의 이름을 걸고 피드백을 주시면 좀 더 받아들이기에 좋을듯 합니다.

Just do it!

익명 사용자의 이미지

MasterQ라는 아이디를 사용합니다. 브라우저 바꾸고 나서 로그인을 다시 하는게 귀챃아서 그런것이니 이해해주시기 바랍니다.

어떤 부분 때문에 까려는 의도라고 판단하셨는지도 모르겠지만 네트워크 드라이버를 x86에서 짜면 어렵다고 한 부분이 도대체 무엇일까하는

순수한 궁금증으로 질문한 것이니 오해는 없으셨으면 합니다.

보여드릴 코드가 없어서 신뢰하실 필요는 없지만 엔비디아에서 나온 GPU를 한번이라도 쓰신적이 있다면 제가 쓴 코드를 사용은 해보신겁니다 (지금 사용하신다면 지금도 사용하시는거구요). 왜 드라이버가 이 모양이냐고 한다면 별로 할말은 없지만요.

태훈의 이미지

x86이든 ARM이든 네트워크 칩을 제어하는건 동일 합니다만, 해당 아키텍처로 만든 타겟 머신에서 네트워크 칩이 어떤 인터페이스(버스)를 주로 사용하는지가 문제 입니다.

x86 머신에서는 네트워크 칩이 주로 PCI 인터페이스를 사용하고,
ARM 머신에서는 네트워크 칩이 주로 메모리 인터페이스를 사용합니다.

PCI 인터페이스(버스) 제어는 어떨지 모르겠지만, 리눅스 커널 코드를 잠시 뒤져보니 요런 PCI 드라이버가 있네요. PCI를 사용하려면 저러한 루틴을 모두 작성해야 합니다.

메모리 인터페이스는 간단하게 해당 메모리 영역에 읽고(read)/쓰기(write)로 제어 할 수 있습니다.

예를 들면,

#define rx_fifo *((volatile u32 *)0x40000000)
#define tx_fifo *((volatile u32 *)0x40001000)
 
u32
eth_rx(void)
{
    return rx_fifo;
}
 
void
eth_tx(u32 packet)
{
    tx_fifo = packet;
}

이런 씩으로 말이죠.

즉, 각 아키텍처에서 동일한 네트워크 칩이라면 디바이스 인터페이스에 따라서 제어하는게 약간 복잡해질수가 있습니다. 이것도 PCI를 잘아시는 분께는 해당되진 않겠지만 말씀드렸다시피 저는 PCI를 펌웨어 레벨에서 아직 제어 해 본적이 없어요. :)

Just do it!

익명 사용자의 이미지

[MasterQ] 전에도 말씀드렸지만 PCI라고 다르지 않습니다, 다만 hw의 base address를 가지고 오기위해서 bootloader나 OS에서 추가로 해줘야 하는 작업들이 있는데 아마도 이부분을 device driver와 합쳐서 생각하셔서 그렇지 않나 싶습니다.

어쨌거나 응원의 메세지를 쓰려다 질문이 길어졌는데 끈기있게 개발하셔서 앞으로 꾸준한 버전업 기대하겠습니다.

태훈의 이미지

좀 있다가 홈페이지나 메일링 만들게 되면 이 쓰레드에 공개 하겠습니다.

지금 당장은 다른 급한 일이 있어요.

백수가 왜이리 바쁜지 참;;;

Just do it!

adoregnu의 이미지

허허허~ 재미난 일을 하고 있구나..

sjpark의 이미지

형~ :D

오타쿠 같은 취미에 밥줄이랑도 관계 없는 일이라서 걍 재미로 하고 있었어요 ㅋㅋㅋㅋㅋ
형도 같이 하실래요~? ;)

익명 사용자의 이미지

실력은 미천하지만 돕고 싶습니다!!!

네트워크 스택에 아직 IPv6 가 없는 듯 싶은데 .. 참여하고 싶군요 ㅎㅎㅎ

gurugio의 이미지

이정도면 엄청난 반응인것 같습니다.
기분좋으시겠어요 ;-)

저도 자극이 됩니다. 열심히 해야겠습니다.

park7275의 이미지

가끔 들려서 구경하다..오늘은 정말 멋진 글을 본것 같습니다.

미천한 실력으로 참석을 해보고 싶은 마음이 굴뚝같네요.

지난 회사에서 Tapping Packet을 분석하는 TCP/IP스택을 개발한 경험이 있긴한데
이미 TCP/IP는 구현하셨다고하니..

뭐 조그마한 부분이라 참여를 했으면 참 좋겠다는 생각이 듭니다.

아니더라도..

진짜 이런 시도에 대해 힘찬 박수 쳐드리고 싶네요

:) 화이팅 이십니다.

[KILL] 죽을각오로.........

태훈의 이미지

http://news.naver.com/main/read.nhn?mode=LSD&mid=shm&sid1=105&oid=031&aid=0000234835

Quote:

현존 제품들과 다른 '웹 기반 OS'로 안드로이드보다는 클라우드형인 '크롬OS' 쪽에 가깝다"고 말했다.

본 프로젝트는 지경부에서 진행하는 소프트웨어 마에스트로 과정에서 2차 프로젝트로 시작했던 프로젝트입니다. (결과는 사업성이 없다는 이유로 떨어졌습니다.) 그래서 그런건지 이번에 지경부에서 진행하는 OS 프로젝트 컨셉이 제 OS와 거의 유사하네요. 프로젝트를 시작할때 분명 저작권은 본인에게 있다고 구두로 들었고 서류상에도 저작권에 대한 내용은 아무것도 없었는데 말이죠.

특허라도 쓸걸 그랬나 봅니다;;

아참, 운영체제 이름 정했습니다. DINOS(DIstributed Node Operating System) 입니다. 운영체제 공부할때 공룡책을 감명깊게 본것이 어느정도 영향을 끼쳤습니다.

홈페이지는 미디어 위키을 쓰기로 하였고, SCM(Source Code Management)은 github 쓰기로 하였습니다. 구글 그룹스를 사용해서 커뮤니케이션을 할 예정이구요.

현재 작업 공간이 없어서 잠시 블록 상태 입니다. ㅠㅠ

Just do it!

chisquare88의 이미지

다이노스 프로야구 엔씨 다이노스랑 겹치는데 괜찮나요?

χxχ=χ^2
GIS SW 개발자

태훈의 이미지

상관 없습니다.

Just do it!

normalized.signal의 이미지

매우 관심이있습니다. 혼자 많은걸 해오셨군요.

ELF, PE 호환도 생각해본적이있었는데

이미 훌륭하게 잘하고 계시는분을 뵙게됐네요

태훈의 이미지

가장 현실적이고 실용적인 방향(approach)은 리눅스 커널에 WINE을 포팅하는 것이죠.

저는 재미로 만드는 거라서 맨땅에 헤딩하고 있습니다.

Just do it!

normalized.signal의 이미지


이미 공개 하신건가요?? 한번 보고싶습니다.

태훈의 이미지

아직 공개 안했어요. 홈페이지 만든다고 스트레스 받아서 지체되고 있습니다.

언젠간 나옵니다. ㅎㅎ

Just do it!

jachin의 이미지

홈페이지 만든다고 스트레스 받으신다니...;;;;
어서 달려가서 도와드려야겠어요. ^^);;;;

이번주 주말에 연락드릴께요. :)

spkpc의 이미지

이런거 만들려면 갓 대학? 대학원 나온정도론 어림도 없겠죠?..
여기 글쓰시는 분들 대학졸업후 혹은 이직시 주로 어떤 직장에 지원하셨고 어떤 업무를 보셨는지 궁금합니다.
S 및 L사같은 대기업출신이신가요?

페이지