i think my sources has a lot of draft and jinks now, and its not a time for pushing it somewhere. but i collect it my repository. Unfortunately Mach sources dont able for collecting many different platforms and architecture, and all directory structures should be remaked, its a hard work and i think its not need, while my arm port dosnt property work. so - when i will have real interesting, i will make patches, because now u can run this port only on one my platform ). i try do not change general part of kernel, ofc, but now it has a lot of debugging information. > Wow, that's cool! Perhaps you should share the source that you already > have, so we can already comment on how it is organized, how fine the > patch is, etc. > >> for next step I should have start module and debug trap/rpc and >> user/kernel context switching, but now I stuck. I dont know what I >> should do. In one hand I have a long path with libc/hurd building, >> then making arm9 libc port and than hurd's micro-server arm port, in >> other - forget about libc, make own small "libc", where all syscalls >> makes as asm includes, use it for debugging my micro-kernel, and then >> hope what true-libc will property work. > >> I tried do build libc/hurd a >> lot of times, but still have a huge amount of linking errors, yes, i choose this path. i made a small hello server for x86, it in attachment. it help me with working on arm port. this server build as static and has minimal count of sources (now it hasn't all sources from libc, but compiled with them). also this example has a syscall example. this server should be load at bootstrap (like ext2fs.static) with $(task-create) $(task-resume). after boot u can see it in ps aux. if i place a dead loop "while(1)", this task will be have all 99.9% cpu. so - syscall work in this application. > I guess so, glibc is very demanding in terms of architecture support. > > I think having a very simple small libc is a good thing to first make > sure that system calls are working properly. Maybe you should also > implement an arm port of the Mach kernel debugger, kdb. > > Then you can probably duplicate the i386 parts of the hurd directories > of eglibc, and replace all the code of the functions with some abortion, > to get things linked easily and then slowly start progressing in the > initialisation code. At first, disable signal handling, you will most > probably not need it at first, and that will relieve you from having to > port libthreads already. > > Samuel >
Attachment:
example.tar.gz
Description: GNU Zip compressed data