Date: Sat, 23 Jun 2001 10:22:29 +0930 From: Greg Lehey <grog@FreeBSD.org> To: Mike Meyer <mwm@mired.org> Cc: j mckitrick <jcm@FreeBSD-uk.eu.org>, Michael Lucas <mwlucas@blackhelicopters.org>, Dag-Erling Smorgrav <des@ofug.org>, freebsd-chat@FreeBSD.ORG Subject: "You are not expected to understand this" (wase: most complex code in BSD?) Message-ID: <20010623102229.I25309@wantadilla.lemis.com> In-Reply-To: <15155.13183.377957.392221@guru.mired.org>; from mwm@mired.org on Fri, Jun 22, 2001 at 07:01:03AM -0500 References: <20010621233210.A37804@dogma.freebsd-uk.eu.org> <xzp7ky5e4ua.fsf@flood.ping.uio.no> <20010622062238.A45123@blackhelicopters.org> <20010622114548.A51977@dogma.freebsd-uk.eu.org> <15155.13183.377957.392221@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 22 June 2001 at 7:01:03 -0500, Mike Meyer wrote:
> j mckitrick <jcm@FreeBSD-uk.eu.org> types:
>> On Fri, Jun 22, 2001 at 06:22:38AM -0400, Michael Lucas wrote:
>>> When I took the two-day FreeBSD Internals course McKusick taught, he
>>> brought up the context-switching code.
>>>
>>> The original UNIX authors were not much on comments. When they put a
>>> comment, it was to explain something really, really, *really* difficult.
>>>
>>> Apparently there was a seven-word comment in the context switching
>>> code that gave him a bit of a start: "You are not expected to
>>> understand this." Don't know if it's still there, but it's still
>>> probably pretty scary.
>>
>> Is this supposed to be in C or asm? I thought context switches
>> were among the only asm/machine dependent code.
>
> For the v6 kernel, this is in C code. I never went looking for it in
> later code, so I don't know when it vanished.
It went away again in the Seventh Edition.
> The comment in question is a couple of paragraphs, followed by that
> seven-word note. If I remember correctly - my copy of Lyons being in
> storage - the code was the context-switching code, and what was
> being explained was the mechanism that was used to start the first
> process, which involved very machine-dependent work so that that
> code would do the job.
Well, in fact it was any new process. Here's the entire function (so
shoot me) from /usr/sys/ken/slp.c. In those days, the system was
stored in the directories ken and dmr, indicating who worked on what.
/*
* This routine is called to reschedule the CPU.
* if the calling process is not in RUN state,
* arrangements for it to restart must have
* been made elsewhere, usually by calling via sleep.
*/
swtch()
{
static struct proc *p;
register i, n;
register struct proc *rp;
if(p == NULL)
p = &proc[0];
/*
* Remember stack of caller
*/
savu(u.u_rsav);
/*
* Switch to scheduler's stack
*/
retu(proc[0].p_addr);
loop:
runrun = 0;
rp = p;
p = NULL;
n = 128;
/*
* Search for highest-priority runnable process
*/
i = NPROC;
do {
rp++;
if(rp >= &proc[NPROC])
rp = &proc[0];
if(rp->p_stat==SRUN && (rp->p_flag&SLOAD)!=0) {
if(rp->p_pri < n) {
p = rp;
n = rp->p_pri;
}
}
} while(--i);
/*
* If no process is runnable, idle.
*/
if(p == NULL) {
p = rp;
idle();
goto loop;
}
rp = p;
curpri = n;
/*
* Switch to stack of the new process and set up
* his segmentation registers.
*/
retu(rp->p_addr);
sureg();
/*
* If the new process paused because it was
* swapped out, set the stack level to the last call
* to savu(u_ssav). This means that the return
* which is executed immediately after the call to aretu
* actually returns from the last routine which did
* the savu.
*
* You are not expected to understand this.
*/
if(rp->p_flag&SSWAP) {
rp->p_flag =& ~SSWAP;
aretu(u.u_ssav);
}
/*
* The value returned here has many subtle implications.
* See the newproc comments.
*/
return(1);
}
More interesting is dmr's comment some years later:
On 2 Apr 92 09:34:24 GMT, dmr@alice.att.com (Dennis Ritchie) wrote:
>
> People might be interested in more of the context
> of the famous `you are not expected to understand this' comment.
> (Tim Smith is wrong on the details.) It was made somewhat in
> the spirit of `this won't be on the exam,' not as a contemptuous
> challenge. Nevertheless, people did find it necessary
> to understand it, and the comment was too flippant.
>
> And of course, the real joke was that we did not understand
> what what was really happening either: the setu/retu mechanism
> of pre-Seventh Edition Unix was basically unworkable,
> because it depended inextricably on subroutine calling
> conventions of the PDP-11 implementation, and more fundamentally
> because it was not the right way to do things. Specifically,
> as the comment says, `savu' arranges that a routine
> that subsequently calls `retu' jumps out not to
> a location near the `savu' (as with setjmp/longjmp),
> but to the routine that called the routine with the `savu.'
>
> Here is the surrounding code, direct from Sixth Edition Unix,
> file slp.c, dated Jul 18, 1975.
>
> You still aren't expected to understand it.
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010623102229.I25309>