Hi Niels, Thanks for your reply. The RTOS is something called xilkernel, basically a royalty-free posix-like microkernel from Xilinx, targetting their FPGA-based CPUs (MicroBlaze and PPC hard-core).
We currently handle Linux support for the MicroBlaze architecture, and have a basic demo of MicroWindows running on that. If we can get MicroWindows coverage on another OS on this platform then obviously it's helpful. Upon a closer look I found that the threads implemention is basically pthreads, so that's a good sign. I agree re: single application support etc, keeping it simple makes a lot of sense. Thanks again for your suggestions, John On Fri, Mar 6, 2009 at 10:52 PM, Niels Roest <ni...@directfb.org> wrote: > Hi John. > > Based on your info I cannot give a hard no or yes. > > Static should be no problem. > I strongly advise to use GCC, or a compiler supporting > __attribute__((constructor)) , that's most harm out of the way. > Strong linux dependancies are mainly in the area of drivers, such as > gfxdrivers, inputdrivers, or pretty obvious stuff like Video4Linux. I guess > you will need to code here a bit anyway, so that should be a > take-along-issue. > You should also restrict yourself to single-application, in that way you can > avoid several problems: multi-app uses the fusion kernel module, which can > be avoided by using user-space multi-app support, but that's kinda > deprecated currently; also this means you can avoid the shared memory file > system which relies on mmap and a /dev entry. If you have a flat memory > architecture, you can alternatively rip shm anyway. > For pthreads, I am not sure how successful that will be. Most stuff is > mutex_lock and mutex_unlock, that should be easy, and most stuff is > abstracted in lib/direct/thread.c where the thread handling is done. Take a > look at that file to guesstimate your porting chances. > > Greets > Niels > > John Williams wrote: >> >> Hello, >> >> We're looking into the feasibility of porting DFB to a non-linux >> embedded RTOS. The target RTOS is vaguely posix-like, and can for >> example create a basic memory-based filesystem. It has a threading >> library through it's certainly not pthreads. Shared libraries are >> clearly out, so static-only builds. >> >> At this stage I'd be interested to hear first impressions, from >> "doable but non-trivial" to "don't even think about it!". >> >> A quick hack to the devmem system would probably get us moving re: >> memory access to the display memory and accelerator MMIO region, but >> I'm more concerned about other assumptions in DirectFB that require a >> full blown filesystem-backed OS. >> >> Porting stuff like libjpg, libpng, zlib etc won't be too much of a >> problem. >> >> Any comments greatly appreciated, or pointers to others having tried >> this before. >> >> Thanks, >> >> John >> > > > -- > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > -- John Williams, PhD, B.Eng, B.IT PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663 _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
