From owner-cvs-all  Mon Nov 29 15:58:46 1999
Delivered-To: cvs-all@freebsd.org
Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10])
	by hub.freebsd.org (Postfix) with ESMTP
	id 33C7615508; Mon, 29 Nov 1999 15:58:36 -0800 (PST)
	(envelope-from jeremyp@gsmx07.alcatel.com.au)
Received: by border.alcanet.com.au id <40328>; Tue, 30 Nov 1999 10:51:12 +1100
Content-return: prohibited
Date: Tue, 30 Nov 1999 10:58:24 +1100
From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>
Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c
 src/sys/libkern arc4random.c src/sys/sys libkern.h
In-reply-to: <23989.943914502@critter.freebsd.dk>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: "Justin T. Gibbs" <gibbs@FreeBSD.ORG>,
	Warner Losh <imp@village.org>,
	Matthew Dillon <dillon@apollo.backplane.com>,
	Dan Moschuk <dan@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG,
	cvs-all@FreeBSD.ORG
Reply-To: peter.jeremy@alcatel.com.au
Message-Id: <99Nov30.105112est.40328@border.alcanet.com.au>
MIME-version: 1.0
X-Mailer: Mutt 1.0pre3i
Content-type: text/plain; charset=us-ascii
References: <199911292125.OAA60469@caspian.plutotech.com>
 <23989.943914502@critter.freebsd.dk>
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

On 1999-Nov-30 09:28:22 +1100, Poul-Henning Kamp wrote:
>In message <199911292125.OAA60469@caspian.plutotech.com>, "Justin T. Gibbs" wri
>tes:
>
>>Actually, if I could put all of my initialization and firmware into
>>a separate section and "dump it" after I've loaded it into the card,
>>I'd be happy.  The assumption, of course, would be that the probe
>>module could be reloaded again should a card be inserted (i.e. the
>>probe module would not be located on the device (or sub-device of that
>>device) being activated).
>
>Right now we lack a way to put the RAM occupied by loader-preloaded 
>images/modules to gainful after they have exhausted their useful
>life.

If we just want the RAM back (and aren't concerned about the KVM), how
about enabling paging for (safe parts) of the kernel[*].  (Most of) the
initialisation code and associated tables are obvious immediate
candidates.  (As is the SYSCTL_* stuff).

Unlike a normal executable, the kernel would start fully resident and
then once it was operational, bits could be paged out as the RAM was
needed.

This approach has the advantage that the code/data can be paged in
later (to allow for PC-card style device juggling).

The problems I can see are:
1) The kernel would need to know it's disk-resident inode if it
   was to page bits in.
2) We need a way to be able to control pageability at runtime (so
   that drivers associated with swap devices don't page out).

[*] Which we can indicate by placing the text/data/heap into different
    sections (eg __attribute__((section("text_pageable")))).

Peter


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message