Date: Thu, 4 Jan 1996 10:57:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, gibbs@freefall.freebsd.org, phk@critter.tfs.com, jkh@time.cdrom.com, obrien@cs.ucdavis.edu, freebsd-hackers@FreeBSD.org Subject: Re: X for install Message-ID: <199601041757.KAA18080@phaeton.artisoft.com> In-Reply-To: <199601040210.MAA09725@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jan 4, 96 12:40:56 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > You need a distinction between low persistance (probe code, etc.),
> > medium persistance (buffer pool allocations), and high persistance
> > (kernel and non-transient modules) memory objects to prevent serious
> > fragmentation in an autoload process.
>
> Why? You load a driver, it sets up whatever it needs in terms of buffers,
> and then probes. If the probe succeeds, you attach it, if it fails, you
> throw it all out.
>
> The problem with fragmentation is in autodiscard, not autoload.
I agree. How do you fix it?
Typically, I'd say either PIC the code or put drivers in their own
per driver address space.
The "easiest" would be to load them, map them into a "probe space",
call from "kernel space" to "probe space", and on a hit (where you
will keep the driver) remap into "kernel space", unmapping from "probe".
Still doesn't resolve the "I/O vs. non-I/O memory" for ISA DMA, but
its a good start. To do the other, you'd need to relocate the pages
as well as remapping them.
The private address space has the advantage of isolating potentially
nasty ("scribble on the kernel") drivers, and the disadvantage of
additional protection domain crossing (ala NetWare 4.x "memory
protection").
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601041757.KAA18080>