Hello, On Tue, Jun 1, 2010 at 8:25 PM, David Given <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 28/05/10 00:00, Andrew Dennison wrote: > [...] >> I can describe it in general terms. > [...snip...] > > That's very interesting; it's nice to hear how this sort of thing works > in the real world. ARM, I presume? If I may ask, what made you decide to > use Prex and not a more established OS like ECOS or FreeRTOS? > > [...] >> I would like to add features to Prex like tickless operation, Futexes >> and a better model for task / server memory operations as a few >> examples but it would be nice to have a proper collaborative >> development model so I'm not effectively maintaining a fork that has >> to be rebased onto the moving target of the "official" tarballs that >> come out occasionally. > > Yes, it's a pity. I suspect Kohsuke Ohtani simply doesn't have > time/inclination to be a source herder. As you know, it's a thankless > and surprisingly complicated job. > > Incidentally, I'm making decent progress with the Cybiko port. I managed > to persuade the build system to produce a linked-together image > consisting of kernel and bootup tasks, which lets me run them all out of > flash. I've got it booting up into 'user' mode and trying to load > /boot/init. Currently that's failing because I haven't done an H8300S > elf relocator yet. But it's running multiple processes and threads, > interrupts are working, the timer is running --- no preemption or > exceptions yet, but that's not bad for under a week's work. > > The biggest hurdles in the code were getting my head around the rather > strange and undocumented way user/kernel stacks work (it's not obvious > it's necessary to remember what your kernel stack is when switching to > user mode, and switching back to it on a syscall or interrupt). And > syscall_ret has nothing to do with returning from system calls. > > However, the really nasty bits were (a) figuring out how to drive ld to > link my image together in really non-standard ways and (b) figuring out > the build system. Prex's Make-based build system is a paragon of > excellence compared to most Make build systems, but it's still a Make > build system and therefore inscrutable and horribly inflexible, and I > had to rewrite big chunks of it to support my kernel XIP stuff.
Please, keep the make/gmake build system. It may be a bit clumsy but at least it's portable and already present on all major OSs. I really don't want to install yet another make alternative for every project i [try to] participate into :) > It just so happens that I have a build tool of my own <plug> > http://primemover.sf.net </plug> that is ideally suited for this sort of > project. Would anyone be interested in a new, better build system? > > - -- > ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── > │ > │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } > │ --- Conway's Game Of Life, in one line of APL > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkwFQqQACgkQf9E0noFvlzjSyACfUODseY2hCx2kLYBE3ibMjK95 > M2oAniw+rpONMOXtmC28ZGpxlxValjmC > =SPIc > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > > _______________________________________________ > Prex-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/prex-devel > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie ------------------------------------------------------------------------------ _______________________________________________ Prex-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/prex-devel
