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.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
