On Sat, May 24, 2008 at 2:58 PM, William Case <billlinux@xxxxxxxxxx> wrote: > Thank you Manish; > > I think I am starting to approach an answer I hadn't thought of. Let me > try it out below. Please correct me if I am wrong. > > > On Sat, 2008-05-24 at 23:40 +0530, Manish Katiyar wrote: > [snip] > >> I don't know about other OS's, but swapper is *handcrafted* using the >> macro INIT_TASK() macro. > > If anyone can confirm that there are other OS's that initiate prcesses > differently from the Linux parent-child process. No details are really > needed, I would just like to satisfy myself that either all OS's > basically use the parent-child modal or that there are several different > ways that it can be done. For example, would the Windows registry > system be an alternative?? > >> 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. >> > To test my understanding by restating: > > At boot time, when starting PID 0 (the swapping process) some?, > several?, all? of the environmental CONSTANTS for my particular system > are loaded and initialized. By passing those constant values on through > a parent-child modal to each new process those new processes don't have > to re-initialize those constants. > > Is this true? And, might there be other reasons to use a parent-child > modal? > >> 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 ? >> > > As stated above, this sounds close to a BINGO. >> > > [snip >> > > >> -- >> Thanks & Regards, >> ******************************************** >> Manish Katiyar ( http://mkatiyar.googlepages.com ) >> 3rd Floor, Fair Winds Block >> EGL Software Park >> Off Intermediate Ring Road >> Bangalore 560071, India >> *********************************************** > -- > Regards Bill Bill, I also think it is useful to realize that UNIX was basically designed for systems that have a MMU even though low-end systems in the late 70s / early 80s did not have them. I believe there were implementations that ran on 286 based hardware without MMUs way back then, but they were very kludgy and definately not the design target for UNIX. With an MMU even if a multi-megabyte app is forked, a majority the memory pages are initially shared between the parent and child. A copy on write system is used to create individual RAM pages if either the parent or the child writes to a specific shared RAM page. Thus the fork call is very efficient and effectively does the minimum amount of work necessary to create a new process from a parent process. Therefore if exec is immediately called by the child, little wasted effort was caused by it being two discrete steps as opposed to one larger step. And as someone else said with current implementations you have a lot of control of exactly what is carried over from parent to child via the clone call and thus can optimize the process. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
