On Sat, May 24, 2008 at 10:35 PM, William Case <billlinux@xxxxxxxxxx> wrote: > Hi Peter; > > On Sat, 2008-05-24 at 23:34 +0800, Peter Teoh wrote: >> On Sat, May 24, 2008 at 11:31 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >> > Sent on behalf of William Case: >> > >> > From: William Case <billlinux@xxxxxxxxxx> >> > Date: Sat, May 24, 2008 at 11:26 PM >> > Subject: fork and exec >> > >> > Hi; >> > >> > I have a fundamental question about why Linux/Unix uses the parent and >> > child modal to start and run new processes. >> > >> > > [snip] > > >> > My question is: Why did the original designers of Multics/Unix choose >> > to use the forking modal to start a new processes? Do not other OSs use >> > other modals? What problem(s) did the fork overcome? Couldn't a system >> > have been designed that just (in some way) starts each process raw? >> >> can u elaborate what is meant by "RAW"?? >> > I was using the word "raw" simply as a metaphor for a process that is > directly placed in memory and accessed without first copying a parent or > being overlaid on a space (buffer) created by a child. > > Two possibilities come to mind: > > 1) Starting a process the same way that PID 0 (swap ??) is started, or, > 2) Starting a process the way that other Operating Systems start a > process. I don't know about other OS's, but swapper is *handcrafted* using the macro INIT_TASK() macro. Suppose if we had to start all the processes from raw probably setting the initial values for the task just as swapper will take some time, and you might want to use some kind of template from you can derive the default values of the raw process quickly.....isn't it ??? ....... And isn't it more beneficial if you get the values from the process which is *most* closest in nature to yours so that you have to change only the few key values like tgid, ppid etc. Ohh and isn't it the same parent child relationship that we were discussing, or in other words it is a raw process getting default values from a closest template ? > > In 2) above, I don't know how other OSes might start their processes but > everything I have read about Unix related systems *implies* that the > parent-child relationship is unique to or central to *nixes. I.e other > OSes must be doing it differently. > > >> I like new ideas....please elaborate....things necessarily have to be >> different all the time.....that's how Windows can survive in >> business.... >> >> > Intuitively, copying a process then overwriting it seems wasteful or at >> > least inelegant, so why is it needed? How does a parent-to-child >> > process enhance its (*nix's) design philosophy? >> > >> > Since forking is at the very core of the kernel, I would like to >> > understand intellectually why the fork process is necessary? >> > > Once again, I am not asking how it is done. I am asking why. Is the > parent-child relationship used because there is, in fact, no other way > to do it? If so why does the claim seem to be made that parent-child > processing is unique to *nixes? > >> > I am not being argumentative, or trolling, or proposing something >> > different or better. Although relatively new to kernel programming and >> > 'C' I am not a complete newbie. I would just like to see in my >> > minds-eye what is going on and *why*. >> > >> > -- >> > Regards Bill >> > > As I read various manuals, read books on the Linux Kernel source code, > and prepare my machine for a virtual Linux system that I can explore and > play with. This fork question, WHY?, keeps niggling at me and in some > ways makes it harder for me to concentrate on the longer view of what is > happening in the kernel. > > -- > Regards Bill > > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- Thanks & Regards, ******************************************** Manish Katiyar ( http://mkatiyar.googlepages.com ) 3rd Floor, Fair Winds Block EGL Software Park Off Intermediate Ring Road Bangalore 560071, India *********************************************** -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
