Some more desctription about the planned architecture:
The user will install an executable kernel (PocketTux.exe) and a file system on his PocketPC device. Then, he can launch the executable kernel like any other application.
This kernel first initializes itself and creates a first /bin/init process. Then it starts scheduling the processes managed by the kernel. This makes the /bin/init binary execute. As this binary will be compiled as a standard ARM-Linux executable (ELF) format, the kernel will load it into its memory and start executing ARM instructions.
This code will start doing system calls. System calls coming from this code will be directed into the kernel which looks up and executed the system call handler for this call in the current process context.
Device access calls (terminal, frame buffer, disk files) are then translated into the appropriate PocketPC system calls handled by the hosting operating system.
This, of course will need some work to gain enough compatibility, as I have no idea about how rich the useage of the Linux system calls are in the /bin/init binary. We might e.g. need to implement most of them to get just the /bin/init running.
Mapping device drivers might also be a lot of bit-fiddling, as we have to map the usual Linux API by using /proc and /dev as well as ioctl() and map this to the PocketPC counterparts for accessing devices like
* Disk (Flash, internal memory, micro disk drives in CF slot)
* Touchscreen (framebuffer)
* Battery manager
* Serial, Infrared, Bluetooth, WiFi
* TCP/IP sockets
And, there is one area which might need a lot of thoughs: memory management. Linux processes assume to have strictly separated virtual memory spaces which can be expanded on demand. This needs to be mapped by the kernel process - which might need support from the Memory Management Unit of the ARM processor. And this is not permitted to interfere with the PocketPC memory management...
So, some additional thoughts to be thought.