miler@osl.csc.ncsu.edu (George Miler) (04/13/91)
I am working on a project at NC State University involving porting
UNIX Version 7 to a 68000 based machine. I have reached a point where
a few things are a bit unclear to me.
In function main(), the internal inits are done and newproc is
called to set up "/etc/init". Once this is done, main() returns and
the code in start.s does a return from interrupt to get things going.
What I don't understand is how sched() gets going. The sched() function
is called if newproc() does not create the init process, followed by
main() returning. But, of course, we need /etc/init so that is done.
main ()
{
......
if (newproc()) <==== true, create /etc/init process
{
copy (/etc/init)
return; <==== exit main, starts copied process
}
sched (); <==== never reached if did /etc/init
}
Any help or explanation you are able to send me will be greatly
appericated.
George Miler
miler@adm.csc.ncsu.edu
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
George B. Miler North Carolina State University
miler@adm.csc.ncsu.edu {decvax, gatech}!mcnc!ncsuvx!cscadm!miler
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=marco@ghost.unimi.it (Marco Negri) (04/13/91)
miler@osl.csc.ncsu.edu (George Miler) writes: > I am working on a project at NC State University involving porting >UNIX Version 7 to a 68000 based machine. Really that old old versione of unix I used 10 (!) years ago? Or are you using another newer powered up version of Version 7? I would like to know WHY you are using V7, what are the benefits for that? > In function main(), the internal inits are done and newproc is >called to set up "/etc/init". Once this is done, main() returns and >the code in start.s does a return from interrupt to get things going. >What I don't understand is how sched() gets going. The sched() function >is called if newproc() does not create the init process, followed by >main() returning. But, of course, we need /etc/init so that is done. > main () > { ************************** Here Proc 0 > ...... > if (newproc()) <==== true, create /etc/init process > { ************************** Here Proc 1 the famous init process > copy (/etc/init) > return; <==== exit main, starts copied process > } ************************** Here Proc 0 Again > sched (); <==== never reached if did /etc/init > } I have checked my V7 sources and they are very similar to the code above. The parent process (0) starts, using newproc() and copy sequence, the first child process with PID 1. The child process PID 1 is the around the world famous init. That forks every other process in unix. The parent process PID 0, continues its execution with sched() function. This function implements the round-robin alghoritm for the process scheduling. Ciao. Marco -- Marco Negri Phone : +39-2-7575242 Universita` di Milano Fax : +39-2-76110556 Dip. Scienze dell'Informazione Telex : 335199 - MIDSII Via Moretto da Brescia, 9 E-Mail : marco@ghost.unimi.it
ken@dali.cc.gatech.edu (Ken Seefried iii) (04/13/91)
In article <1991Apr12.205055.25220@ghost.unimi.it> marco@ghost.unimi.it (Marco Negri) writes: >miler@osl.csc.ncsu.edu (George Miler) writes: >> I am working on a project at NC State University involving porting >>UNIX Version 7 to a 68000 based machine. > >Really that old old versione of unix I used 10 (!) years ago? >Or are you using another newer powered up version of Version 7? >I would like to know WHY you are using V7, what are the benefits for that? > Gee...maybe 'cause it's small, simple and undemanding on resources. It's not like he's gonna get SVR4 running on a 68000 (note: not '030). Actually...v7 is a *really* nice little system, especially compared with it's contemporaries. And remember: Unix was design to be simple and elegant. V7 is a lot closer to that tradition that what is generally run these days. After a long day of walking around in the System V.3.2 or BSD 4.3 sources it's sometime nice to break out your copy of Lions and realise that there was a time when one man could understand it all and do a port in something less than a lifetime. Sometimes when I look at my nearly 2MB Ultrix kernel, I long for the day when a man (a Real Man (tm), mind you...:-)) could run with a couple of his pals pretty comfortably on a PDP-11/45 with 256K memory and a pair of 20MB disk. Not that I *really* wanna go back...it's just that the nostalgia gets you... -- ken seefried iii ken@dali.cc.gatech.edu "If 'ya can't be with the one you love, honey, love the one you're with..."
jim@segue.segue.com (Jim Balter) (04/14/91)
In article <1991Apr12.172939.6348@ncsu.edu> miler@osl.csc.ncsu.edu (George Miler) writes: > main () > { > ...... > if (newproc()) <==== true, create /etc/init process > { > copy (/etc/init) > return; <==== exit main, starts copied process > } > sched (); <==== never reached if did /etc/init > } Do you understand how main () { if (fork() == 0) { childstuff(); return; } parentstuff(); } works? newproc() is just the kernel level equivalent of fork. It returns twice, into two different processes, with a 0 return to the parent and a non-zero return to the child (fork is the other way around). Generally, newproc will create a new process that is pretty much a copy of the current process, and set the pc of the new process to point to some code that will do a return 1. Since the stack is copied, that return will return to the caller of newproc. So the flow of control looks something like <proc 0> main newproc creates new process, returns 0 sched look for schedulable processes find proc 1, start it running <proc 1> [main] [newproc] return 1 exec init at some point, init sleeps or forks to create a new process, which causes sched to be resumed <proc 0> [main] [sched] look for schedulable processes, start one running <proc n> . . . Basically, you need to understand the concept of concurrent processes and how they function under UNIX. Since you are in a class, why not get your instructor or a fellow student to help you?
scottl@convergent.com (Scott Lurndal) (04/16/91)
In article <7101@segue.segue.com>, jim@segue.segue.com (Jim Balter) writes: |> In article <1991Apr12.172939.6348@ncsu.edu> miler@osl.csc.ncsu.edu (George Miler) writes: |> > main () |> > { |> > ...... |> > if (newproc()) <==== true, create /etc/init process |> > { |> > copy (/etc/init) |> > return; <==== exit main, starts copied process |> > } |> > sched (); <==== never reached if did /etc/init |> > } |> |> Do you understand how |> |> main () |> { |> if (fork() == 0) |> { |> childstuff(); |> return; |> } |> parentstuff(); |> } |> |> works? newproc() is just the kernel level equivalent of fork. |> It returns twice, into two different processes, with a 0 return to the parent |> and a non-zero return to the child (fork is the other way around). |> [examples deleted] I seem to recall a caveat in Lyons commentary to the effect of "you're not expected to understand this." :-) scott.
jim@segue.segue.com (Jim Balter) (04/17/91)
In article <4039@risky.Convergent.COM> scottl@convergent.com (Scott Lurndal) writes: >I seem to recall a caveat in Lyons commentary to the effect of > "you're not expected to understand this." That comment applied to the bizarro aretu stuff, which went away in V7. As with so many things, it was hard to understand because it was badly written. There's nothing particularly hard to understand about save/resume or newproc.
clewis@ferret.ocunix.on.ca (Chris Lewis) (04/20/91)
In article <7128@segue.segue.com> jim@segue.segue.com (Jim Balter) writes: >In article <4039@risky.Convergent.COM> scottl@convergent.com (Scott Lurndal) writes: >>I seem to recall a caveat in Lyons commentary to the effect of >> "you're not expected to understand this." >That comment applied to the bizarro aretu stuff, which went away in V7. As >with so many things, it was hard to understand because it was badly written. >There's nothing particularly hard to understand about save/resume or newproc. I seem to remember that to be a reference to the scheduler algorithm itself, and how it interacts with the swapping mechanisms. The V6 scheduler was pretty awful. save/resume and newproc weren't that hard to understand by themselves. -- Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca UUCP: uunet!mitel!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
jim@segue.segue.com (Jim Balter) (04/22/91)
In article <1422@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: >>There's nothing particularly hard to understand about save/resume or newproc. > >save/resume and newproc weren't that hard to understand by >themselves. There seems to be an echo in here. There was no save/resume in the V6 kernel.