Dave Hudson wrote:
> Ah, there's method in my madness :-) If we load a server at boot-time it
> gets put into wired memory so it can have its pages stolen from under it.
> These pages are also in the base 640k of RAM. What I described was to
load
> a boot image of say the kernel, fd, namer, env, a modified tmpfs (that
> supports directories) and a special init process. The init process would
> use fd to read the compressed disk image from the floppy and unpack it
into
> the tmpfs.
Dave, I really like what I hear you saying here. Pardon my ignorance, but
don't
we also need servers for the video display and keyboard (in order to support
the logon screen)? Or is there minimal support for this in the logon
process
itself?
> The biggest problem in running before servers are ready is that their
ports
> aren't registered - I guess we could find a way round this though for a
> special requirement (define a few more "well known" ports that we can wait
> to become active), and it shouldn't be too hard to start executing these
> servers as they're unpacked into the tmpfs.
I really appreciate your "it can be done" attitude. This whole scenario
sounds
like a great thing to me. I would love to see it accomplished, and am
willing to
help.
Here is one reason this might be useful: It would be great to have a lean,
mean
bootable floppy which could serve as the media for a serious hardware
diagnostics
program.
David Eagle
FromFrom vandys@glare.cisco.com Sun May 21 20:00:35 1995
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisc vandys@glare.cisco.com Sun May 21 19:58:31 1995
Received: from glare.cisco.com (glare.cisco.com [171.69.1.154]o.com (8.3/8.3) with ESMTP id UAA00094; Sun, 21 May 1995 20:00:33 -0700
Received: from xmission.xmission.com (root@xmission.xmission.com [198.60.22.2]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with ESMTP id VAA06217; Sun, 21 May 1995 21:39:29 -0700
Received: from xmission.xmission.com (shea@localhost [127.0.0.1]) by xmission.xmission.com (8.6.12/8) by amri.cisco.com (8.3/8.3) with ESMTP id TAA00076; Sun, 21 May 1995 19:58:30 -0700
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id VAA21398; Sun, 21 May 1995 21:56:23 -0700
Message-Id: <199505220456.VAA21398@glare.cisco.com>
X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Gary Shea <shea@xmission.com>
Cc: vsta@cisco.com
Subject: Re: preemption
In-Reply-To: Your message of "Sun, 21 May 1995 22:39:07 MDT."
<199505220439..6.12) with ESMTP id WAA23285; Sun, 21 May 1995 22:39:18 -0600
Message-Id: <199505220439.WAA23285@xmission.xmission.com>
To: Andrew Valencia <vandys@cisco.com>
Cc: vsta@cisco.com
Subject: Re: preemption
In-reply-to: Your message of "Sat, 29 Apr 1995 10:38:21 PDT."
<199504291738.KAA16937@glare.cisco.com>
Date: Sun, 21 May 1995 22:39:07 -0600
From: Gary Shea <shea@xmission.com>
Andrew Valencia writes:
>Currently, when running in kernel mode we can take interrupts which set
>higher priority processes runnable. The code returning from the inWAA23285@xmission.xmission.com>
Date: Sun, 21 May 1995 21:56:23 -0700
From: Andrew Valencia <vandys@cisco.com>
[Gary Shea <shea@xmission.com> writes:]
>I'm looking at the code for interrupt() in trap.c.
>I see the call to check_preempt() inside a test for PRIV_USER,
>which as best I can tell means that when we caught the interrupt,
>the system was running in user mode.
Yes.
>In the kernel-preemption version, I get the impression that the
>call to check_preempt() would be moved outside of the PRIV_USER test.
>We'd only get to that test through check_preempt(terrupt
>handler could--but does not currently--cause a context switch.
I'm looking at the code for interrupt() in trap.c.
I see the call to check_preempt() inside a test for PRIV_USER,
which as best I can tell means that when we caught the interrupt,
the system was running ) and re-scheduling,
>meaning possibly after some other kernel or user process has been
>executing, regardless of whether we were running in user or kernel
>mode. Is that right?
Yup.
>In that case, the possibility of race conditions in the kernel
>is greatly increased, as I sein user mode.
In the kernel-preemption version, I get the impression that the
call to check_preempt() would be moved outside of the PRIV_USER test.
We'd only get to that test through check_preempt() and re-scheduling,
meaning possibly after some other kernel or user process has been
executing, regardless of whether we were running in user or kernel
mode. Is that right?
In that case, the possibility of race conditions in the kernel
is greatly increased, as I see it. In fact, I don't see how they can
be avoided. Could someone please explain whe it.
Absolutely correct. It's not a coincidence that the original UN*X did not
have kernel preemption. It's a powerful simplifying assumption (as is
uniprocessor, FWIW).
>In fact, I don't see how they can
>be avoided. Could someone please explain why, say in the middle
>of p_sema(), we can't take an interrupt, get re-scheduled into
>a user mode process running user code which accesses p_sema()
>for the same semaphore again, and deadlocks?
Note that check_preempt() won't preempt if the current CPU is holding any
locks. Thus, at the beginning of p_sema() (for insty, say in the middle
of p_sema(), we can't take an interrupt, get re-scheduled into
a user mode process running user code which accesses p_sema()
for the same semaphore again, and deadlocks?
I thought I understood before kernel preemption, when you were
guaranteed, if in kernel mode, to stay in kernel mode until
you decide to leave. With kernel preemption I'm ance) where we take the
lock on really lost!
> Andy
Gary
the semaphore structure, we protect the data structure from both
parallel threads on other CPUs, as well as from preemption on the current
CPU.
>I thought I understood before kernel preemption, when you were
>guaranteed, if in kernel mode, to stay in kernel mode until
>you decide to leave. With kernel preemption I'm really lost!
Take a look at kern/sched.c, the check_preempt() routine. Kernel preemption
still has conditions which will prevent preemption from occurring. You need
to be a running thread. You must not be holding any locks. You must not
have explicitly flagged inhibition of preemption.
Regards,
Andy
Received on Sun May 7 16:43:13 1995
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:27 PDT