SCCS, RCS, ISO TRANSPORT, and Kernel Hacking

[Pete Delaney]

BACKGROUND INFORMATION:	    /* Skip to QUESTION[1] if you are short on time */

	We are about to add a tracing facility to 4.2BSD that
I implemented on the Level-6.  It was quite usefull in seeing the
flow between kernel modules and made integrating of the sub-systems,
like sockets and tty, easy into the V7 kernel.

	The general method is as follows.  The the C compiler increments and
and decrements a global variable on function entry and exit.  The kernel
functions have TRACE_PRINTF() at function entry's, exits, and significant
points.  Each proc has a flag indicating which sub-systems we are
interested in tracing.  If any proc desire tracing the TRACE_PRINTF()
macro expansion will call a tprintf() which checks if the current proc
want to be traced.  If so the putc() writes it's data to a trace buffer
which, when full, is written to a mag-tape.  The mag-tape output has
as dedicated uba map register and uses the direct data path.  Interupts
are global and thus if any procs are tracing they are recorded.  This
allows us to run muli-user in the evenings with only marginal performance
degragation while we can test new kernel functions.  If anyone wants more
detail on this method I can send a memo which goes into more detail.
The resultant print of the tape looks like:
			.
			.
			.
<5677,0x35,pid:62,2>	socket(domain:2, type:2, protocol:0): entry
<5678,0x35,pid:62,4>	  pffindtype(family:2, type:2): entry
<5679,0x35,pid:62,4>	  pffindtype(): returns(pr:0X000407A4.0001)
<5680,0x35,pid:62,5>	  m_getclr(canwait:1, type:MT_SOCKET): entry
			.
			.
			.
<5691,0x35,pid:62,4>	  udp_usrreq(so:0x004300, req:'ATTACH', ...): entry
<5692,0x35,pid:62,5>	   in_pcballoc(socket *so:0X004305, inpcb *head:0X3bcc0)
<5693,0x35,pid:62,6>	    m_getclr(canwait:0, type:MT_PCB): entry
			    /* NOTE: 0x35 is the NORMAL interupt level */

If anyone is interested in getting a fuller example, I suggest you ask
mcvax!vmucnam!lvbull!sylvain to send you a larger sample; as their
group is using it now to debug the ISO transport.

			
	The latest 4.*BSD Kernel that we have is maintained with SCCS.
It seems reasonable to continue that environment or switch over to RCS.
However, nether seems possible right now.  The sources for SCCS are not
to be found (I think) and the SCCS get command is necessary for the
sccstorcs command to operate.  

	Since a System V license is required for 4.2BSD their is no
reason we can't use the sources from the System V release.  However,
that seems like a source for problems.  



QUESTION[1]:
	HAS ANY ONE OUT THERE IN NET-LAND A COPY OF SCCS
	ALREADY ESTABLISHED IN THE BERKELEY KERNEL.  OR,
	PERHAPS THERE ARE NO PROBLEMS JUST CPIO'ing IT
	OFF THE RELEASE TAPE?  (need new cpio perhaps?)


QUESTION[2]:
	ON THE LEVEL-6 WE HAD NEITHER SOURCE CONTROL SYSTEM.
	WHICH DO 'YOU GUYS' THINK IS BETTER, AND WHY?
	IS THE FACT THAT OUR CURRENT RELEASE IS SCCS BASED
	SUFFICIENT REASON TO STAY WITH IT?

QUESTION[3]:
	ARE THEIR ANY BETTER WAYS OF DEBUGING?




FUTURE ACTIVITY:
	I am about to start hacking:
		sys/subr_prf.c
		sys/sys_sysent.c
		vax/uba.c
		vaxuba/ts.c

	then we will start adding sylvains ISO transport network.  After that
	we will modify an X25 (CSNET InCard?) and il.c interface to be ISO 
	compatible.

	Any general sugestions and comments are appreciated.