From owner-freebsd-hackers Thu Jul 1 11:50: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 6639614D26 for ; Thu, 1 Jul 1999 11:50:04 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id NAA19145; Thu, 1 Jul 1999 13:50:02 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id NAA11835; Thu, 1 Jul 1999 13:50:01 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id NAA15793; Thu, 1 Jul 1999 13:50:01 -0500 (CDT) Date: Thu, 1 Jul 1999 13:50:01 -0500 (CDT) From: Jonathan Lemon Message-Id: <199907011850.NAA15793@free.pcs> To: peter@netplex.com.au, hackers@freebsd.org Subject: Re: npx0 to set maxmem broken in -current? X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >Personally, I think we should use a kernel environment variable passed in >from loader, since kern_envp is available *real early*, from the very >beginning of init386(), which is called form locore just after going >virtual. It needs a couple of tweaks to get this to work, and in >particular, the environment variable will have to override the VM86 >calls. You'd still have to perform the VM86 calls, since one of the things they do is generate a map of where the useable memory segments are. The environment variable would be used later (at the same point where the npx0 hack is) in order to cap Maxmem. I like the idea of being able to say: set console=comconsole set maxmem=.... boot -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message