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>