From owner-freebsd-arch Wed Nov 3 13:11:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5497214CE0 for ; Wed, 3 Nov 1999 13:11:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA16740 for ; Wed, 3 Nov 1999 22:11:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA89368 for freebsd-arch@freebsd.org; Wed, 3 Nov 1999 22:11:03 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 8BB8314C83; Wed, 3 Nov 1999 13:10:50 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Thu, 4 Nov 1999 08:05:18 +1100 Content-return: prohibited Date: Thu, 4 Nov 1999 08:10:43 +1100 From: Peter Jeremy Subject: Pageable kernels (was Re: diskless boot roadmap) In-reply-to: <99110304555400.19188@nomad.dataplex.net> To: Richard Wackerbarth Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov4.080518est.40325@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <99Nov3.160403est.40416@border.alcanet.com.au> <199911030515.VAA02306@dingo.cdrom.com> <99Nov3.163119est.40376@border.alcanet.com.au> <99110304555400.19188@nomad.dataplex.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [This is heading more towards -arch than -current] On 1999-Nov-03 21:53:07 +1100, Richard Wackerbarth wrote: >> How much of the probe code can we move into userland? >Or alternately, transient kernel memory. Use it, then lose it. IMHO, there are some items (like the PNP ID tables) that really belong in a user-editable file, rather than the kernel source. This file could then be read by /boot/loader (and maybe a runtime daemon similar to pccardd). And taking the idea of transient kernel memory a bit further: How about supporting paging within the kernel? At least for text space, this would seem to be a fairly simple matter of tagging functions as pageable (eg add '__attribute__((section("text_pageable")))' to the function declaration), and treating that section of KVM the same way as user text space (though probably with a higher preference for being resident and a higher priority for paging in). Paging data may be a bit trickier, but would seem to be amenable to a mixture of variable attributes and a new `pageable' flag for kernel malloc. Initialisation code is an obvious candidate for paging, but I suspect that everything except interrupt handlers, the paging code and device drivers associated with the paging devices could be made pageable. In fact, the above all sounds so obvious and simple that I wonder if I'm missing something... Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message