thank you Rene for the in-depth discussion. On Wed, Oct 8, 2008 at 1:56 AM, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: > On 07-10-08 17:55, Peter Teoh wrote: > >> thank you for the answer. next question (out of curiosity, sorry if >> it is overstretching the OP) is in architecture without any MMU, >> what does syscall like fork() get translate into? > > Please note that this is not something generic for a (fork-implementing) OS > on a non-MMU architecture or anything. It's perfectly possible to implement > fork() with all the expected semantics simply by actually physically copying > the address space and for that you don't need an MMU. > > For example MINIX, originally written for the Intel 8086 (a CPU without > MMU), did/does. Heck, all "original" UNIX implementations did ... > >> the fact that fork() does not exists on non-MMU is discussed >> everywhere, but then how is it replaced? For example, the following >> seemed to imply fork() inside application should continue to compile >> (but should not give error when run, right?): >> >> >> http://mailman.uclinux.org/pipermail/uclinux-dev/2003-September/020871.html >> >> http://mailman.uclinux.org/pipermail/uclinux-dev/2003-September/021010.html >> >> is it just a passthrough? > > ... but uclinux doesn't it seems. > > I've never really concerned myself with uclinux but I assume this was done > mostly as a forced optimization: actually copying the address space is > ofcourse rather slow and given that the vast majority of fork() calls is > followed by a rather immediate exec() (which immediately retires that > address space again) this will often be totally in vain. In that sense, I > suppose it makes sense to force ports of fork() using applications ... > > ... to, generally, vfork() using applications. vfork() is a "fake fork" (or > at least, can/will be implemented as such) which historically exists to > avoid that exact copy -- see the man page. > > As said, never really concerned myself with uclinux, but no, I don't believe > this will be an automatic translation thing (ie, still compile) but will > have to be done manually. > >> And does "Task-struct" even exists in non-MMU architecture? > > Again with the slight disclaimer towards the specifics of uclinux, yes, > definitely. The task_struct is the embodiment of the schedulable entity (the > process, if we ignore threads) and if uclinux were a single-tasking OS it > would be very overly complex for its purpose. > > Rene. > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
