Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Jul 1999 13:50:01 -0500 (CDT)
From:      Jonathan Lemon <jlemon@americantv.com>
To:        peter@netplex.com.au, hackers@freebsd.org
Subject:   Re: npx0 to set maxmem broken in -current? 
Message-ID:  <199907011850.NAA15793@free.pcs>
In-Reply-To: <local.mail.freebsd-hackers/19990701181449.846AA8A@overcee.netplex.com.au>
References:  <local.mail.freebsd-hackers/14203.43667.496647.806250@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-hackers/19990701181449.846AA8A@overcee.netplex.com.au> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907011850.NAA15793>