On Sunday 22 October 2006 21:56, you wrote:
Hello,
I must confess your mail came as a big surprise, since nobody seemed to care about the XGeNOS project for quite some time, but of course the surprise is a pleasing one ;-)
Considering your thougths and ideas below, I'll try to figure out as much as possible for the moment ... I've been thinking over some of them, but it will take me some time to get through it all ...
I would want to know if this is possible to use fiasco and a uclibc-nptl rewrote in cyclone for a XGenOS fork.
http://os.inf.tu-dresden.de/vfiasco/
Well, vfiasco is an interesting project and complements to some work I'm going to do as a part of my PhD thesis. On the other hand from the viewpoint of the u-kernel API an implementation of X.2 seems to be a good idea, which would rather imply to use the pistachio kernel ...
http://cyclone.thelanguage.org/
Interesting. I never came across that before, but it seems this could solve some problems of mine (not only XGeNOS related ...)
http://www.realitydiluted.com/nptl-uclibc/
http://www.busybox.net/cgi-bin/viewcvs.cgi/branches/uClibc-nptl/
uhm, I'd be happy if there was an alternative to uClibc as my previous experiences with uClibc have shown that its code is from so many different sources that it's sometimes quite hard to keep the overview. I guess the code is quite hard to maintain which IMHO is not the perfect basis for secure software ... But, I cannot see any alternative to uClibc for the moment ... I'll probably have a look at Peter Anvins klibc in some time, maybe that could be an alternate starting point for a suitable C-library ...
Could we be able to merge the best ideas from these projects ? :
http://www.marcus-brinkmann.org/hurd-ng.pdf
http://www.research.ibm.com/K42/papers/eurosys06.pdf
http://domino.research.ibm.com/comm/research_projects.nsf/pages/prose.ind ex.html
Lots to read ;-) Give me some time to check that out ...
Which Device Driver Framework could be the best and that will let us reuse the maximum of linux drivers code ? :
http://www.jaluna.com/doc/c5/html/BSPDevGuide/c3882.html
http://sourceforge.net/projects/jaluna/
http://www.circlemud.org/~jelson/software/fusd/ http://www.circlemud.org/%7Ejelson/software/fusd/
Well, IMHO the device driver framwork is the crucial point of the whole system. I've got some ideas that derive partly from some of the projects mentioned above, and others (e.g the sawmill project, etc.). I agree that reusage of existing driver code must be on of the project goals, but if this turns out to be of some security risk, one should think of some other solutions ... but that's just my EUR 0.02 ...
Could haskell be a good alternative to C ? :
http://programatica.cs.pdx.edu/House/
http://www.ertos.nicta.com.au/research/sel4/
http://repetae.net/john/computer/jhc/
http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ http://www.cse.unsw.edu.au/%7Echak/haskell/c2hs/
I must confess I haven't dealt with Haskell yet, so I can't say anything about that ...
Time is not a problem, I would to know only which basis could be the most suitable for an innovative project ...
Let's stay on contact, any ideas are welcome. Pls. use the above mail-address (ta@xgenos.org) if possible. I'm probably going to set up a mailinglist in some time ...
Best regards,
-ta