Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Question about TEST:
Message-ID: <8711012051.AA13550@cory.Berkeley.EDU>
Date: Sun, 1-Nov-87 15:51:42 EST
Article-I.D.: cory.8711012051.AA13550
Posted: Sun Nov  1 15:51:42 1987
Date-Received: Thu, 5-Nov-87 21:00:57 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 27

>I thought it was a task, not a process. Speaking of which, could you explain
>how you're building the process that's handling the debugging code? It's kind
>of muddy exactly what's going on here.
>
>Are you going to write a sample exec device next? (mattdisk.device).

	Certainly.  DOS will create the device driver as a process.  Thus,
it is a process.  If you look at the source for the debugging process, you
will note that I make a CreateProc() call.  So the debug process is, well,
a process also.  If I had used CreateTask() it would have been a task.
(Side note: Note that you have to face a seglist in CreateProc()).

	Since the debug process is in the same binary as the device driver, all
global variables are shared.  The debug process simply uses the device 
driver's library base variables (SysBase, DOSBase), since they would not be
different if the device driver openned the libraries itself.  Remember that
the link library routines are also shared, but since they simply make
run-time library calls this is ok.

	A separate debug process is needed to prevent confusion on the device
driver process's message port.  This port is used by the device driver process
to handle incomming packets and thus cannot be used as a reply port to 
outgoing packets (which is what most DOS library calls require).  So, we 
need a separate debug process to make the DOS library calls since it's 
process-message-port is free.

					-Matt