Re: [microblaze-uclinux] Re: multiprocessing

[Matthew Rubenstein <email@xxxxxxxxxxxx>]

On Sun, 2004-04-04 at 20:02, Greg Ungerer wrote:
> Hi Matthew,

Hi Greg (et al),
	Children of fork()'ed processes inherit their parent's state, with page
tables managed by the MMU (unless I'm mistaken). 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. And there's no simulated (interleaved) multitasking; the
parent halts until the child terminates and is destroyed. All those
decreasing subsets of fork() offer progressively less support for
multitasking, which must be replaced with alternates. Building from
vfork(), they're usually incomplete, and set off towards the inadequate
starting point of fork() itself, a problematic simulation of true
multiprocessing.

	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.

	With MB/uCL's arrival, we've still got a dancing poodle: interesting
not because it dances well, but because it dances at all. Once we've got
a framework for bridging procedural/object programming with
reconfigurable logic, in the same codebase / address space / gates
network, in the same runtime process, we'll be able to get the best of
both worlds, and shed the old straitjackets of each world of sequential
programs and parallel programming. Personally, I'm hoping for executable
flowcharts, with schematic blocks of microcoded instructions.


> Matthew Rubenstein wrote:
> > On Fri, 2004-04-02 at 00:09, Greg Ungerer wrote:
> >>Matthew Rubenstein wrote:
> >>>	Where are the apps? Linux on FPGA is a means to an end, not an end in
> >>>itself: familiar development environment for new FPGA tools. Is there an
> >>>archive of apps that run under MicroBlaze? With MicroBlaze omitting
> >>>fork() in favor of vfork() (inherited from uCLinux, with no MMU), even
> >>>the ancient Unix multitasking patterns are unavailable.
> >>
> >>I don't understand what you mean here. uClinux supports true
> >>multitasking, using vfork doesn't preclude this. It does
> >>preclude the child running in the parents context, but there
> >>is ways around this, and in many typical embedded applications
> >>it is just not a problem in practice.
> > 
> > 	Using fork() is a very common technique for multitasking; vfork()'s
> > omission of the parent's page tables and access to other volatile data
> > does not allow its use in simple porting of existing source code to
> > uCLinux.
> 
> In itself this is a wrong. Simple porting is true for most
> programs to uClinux. The vfork/fork issue only affects a small
> number of "standard" applications (for example apache, samba, etc).
> And like I said, these can still be made to run. Samba is simple,
> just launch it from inetd instead of it running as its own server.
> 
> 
> > But that's an opportunity: the FPGA parallelism is a much
> > better infrastructure than the  roundrobin multitasking simulated by
> > MMUs in other *nixes.
> 
> I agree that the FPGA parallelism is better for parallel tasks.
> 
> But simulated multitasking is not tied to having an MMU.
> Multitasking in uClinux is the same as multitasking in Linux.
> There is no difference, and the same "save-state" technique is
> used. The presence or absence of an MMU is just part of a process
> state that is saved and restored.
> 
> 
> > And without the distraction of fork(), true
> > multiprocessing will underlie the ported MB/uCL apps. This is a virtue,
> > born of necessity, of the MB/uCL platform, which makes it superior to
> > both other uCLinux and even MMU *nix platforms.
> 
> But again, I don't see how having an MMU or not has any impact
> on this. Exposing the possible parallelism is the true power.
> 
> 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/
-- 


(C) Matthew Rubenstein

___________________________
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/