Date: Fri, 16 Jun 2000 20:08:14 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: msmith@FreeBSD.ORG (Mike Smith) Cc: tlambert@primenet.com (Terry Lambert), msmith@FreeBSD.ORG (Mike Smith), arch@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pci.c pcisupport.c pcivar.h Message-ID: <200006162008.NAA12354@usr08.primenet.com> In-Reply-To: <200006152246.PAA00823@mass.osd.bsdi.com> from "Mike Smith" at Jun 15, 2000 03:46:52 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > I _don't_ think it's OK to statically link in all ISA devices, or > > even to load the full driver for each device before deciding to > > discard it because the probe failed to find a device. > > I think there are so few ISA devices left that we care about that it's > fine to load their drivers if and when you give a damn about them, and > then unload them if you decide they failed to load. It's so rare an > event to probe an ISA device that I don't think the difference between > paging in the probe vs. just loading the entire driver is so trivial that > it's not worth arguing about. You don't know you don't need them until after you load them, and their probe fails. By then, you've already potentially fragmented kernel memory in the process. Unless you are prepared to introduce pageable segments for kernel code, this means that the only way to avoid the fragmentation is to either require that zero allocations take place, or load the drivers and the probe routines seperately. If you _are_ going to introduce pageable segments, I withdraw the objection, since it would be just a small change to move pageable segments around to defrag the VM space. Incidently, this would also allow you to make large post-boot contiguous allocations for things like video capture cards, etc., instead of having them reserve contiguous segments of kernel memory up front, when the card is potentially never used during a boot session Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006162008.NAA12354>