pete@ecrcvax.UUCP (Pete Delaney) (04/25/85)
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.
rick@cadtec.UUCP (Rick Auricchio) (05/01/85)
--------
[]
Cast my vote for RCS over SCCS any day. It's easier to use, seems less buggy,
and tends to run faster.
Besides, it maintains the *latest* version and doesn't have to do all that
editing unless you want an old version (much less common). Saves lots of time
and some disk space. This is especially true for updates which consist of a
lot of added code.
SCCS doesn't give you the nice $Log$ stuff, which is handy.
==============================================================================
Opinions expressed have been generated solely by line-noise.
{cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!cadtec!rick N1150G (408) 942-1535
"The sooner you fall behind, the more time you'll have to catch up!"