Re: [microblaze-uclinux] Re: multiprocessing

[Greg Ungerer <gerg@xxxxxxxxxxxx>]

Hi Matthew,

Matthew Rubenstein wrote:
> 	Children of fork()'ed processes inherit their parent's state, with page
> tables managed by the MMU (unless I'm mistaken).

With a standard fork() the child gets a new virtual address space
that looks identical to the parents (often optimized with COW, but
that is not relevant here). It has its own set of page tables that
hold this mapping. The "management" of page tables is done by the
kernel, not so much the hardware. So any processes page tables are
just a part of its "state". A child inherits a _copy_ of its
parents page tables on a fork(). On a vfork() the child uses its
parents page tables.


>  Regardless of the (lack
> of?) the missing MMU as raison d'etre, vfork() offers only preservation
> of parent's state, with a few volatile accesses offered from the child
> to the parent, for write, and fewer for read, and even fewer for return
> to the parent.

Huh?  This doesn't make any sense to me...
What accesses are you talking about?

A child process that modifies the parent state in any way
is broken. From the vfork() manpage:

     The vfork() function has the same effect as fork(), except that
     the behaviour is undefined if the process created  by  vfork()
     either modifies any data other than a variable of type pid_t used
     to store the return value from vfork(), or returns from the
     function  in which vfork() was called, or calls any other function
     before successfully calling _exit() or one of the exec family of
     functions.


> And there's no simulated (interleaved) multitasking; the
> parent halts until the child terminates and is destroyed.

This is true. But it over looks the whole reason that vfork()
was created. _Most_ programs fork() then immediadely exec()
another. And when that exec() occurs the child builds a new
process memory state. At this time the parent then continues -
entering the run queue. So now we have the child and parent
multitasking again (simulated or otherwise).


> All those
> decreasing subsets of fork() offer progressively less support for
> multitasking, which must be replaced with alternates.

There is no decreasing subset.


> Building from
> vfork(), they're usually incomplete, and set off towards the inadequate
> starting point of fork() itself, a problematic simulation of true
> multiprocessing.

Well, I can't say I agree with that. fork() seemes to have served
as quite a strong fundamental primitive over the years. You can argue
its ineffeciency with regard to spawning different programs.


> 	So I am happy that with MicroBlaze/uCLinux, we've got the
> hardware/flexware/OS platform for true multiprocessing in a familiar
> (GNU/Linux) development/execution environment. And without the tempting
> distraction of fork(), the effort to port down the same old wrong road
> starting with vfork() competes with the true path of dynamically
> retrieved (or generated) logic in parallel hardware.

I still don't see it. Having the ability to reconfigure the compute
engine on the fly seems powerful, but I don't see how it will ever
negate the need for something like a fork. Except maybe for the
narrowest of compute tasks. But then that is nowhere near as 
interresting as what we might be able to do with more general systems.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/