From owner-freebsd-hackers Tue Jan 27 11:48:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA22203 for hackers-outgoing; Tue, 27 Jan 1998 11:48:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wcc.wcc.net (wcc.wcc.net [208.6.232.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA22162 for ; Tue, 27 Jan 1998 11:48:43 -0800 (PST) (envelope-from piquan@wcc.wcc.net) Received: from detlev.UUCP (ppp78.wcc.net [208.6.232.78]) by wcc.wcc.net (8.8.7/8.8.7) with ESMTP id NAA19080; Tue, 27 Jan 1998 13:31:31 -0600 (CST) Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.7) id NAA06179; Tue, 27 Jan 1998 13:34:57 -0600 (CST) (envelope-from joelh) Date: Tue, 27 Jan 1998 13:34:57 -0600 (CST) Message-Id: <199801271934.NAA06179@detlev.UUCP> To: doconnor@gsoft.com.au CC: mike@smith.net.au, dag-erli@ifi.uio.no, hackers@FreeBSD.ORG In-reply-to: <199801270651.RAA29592@cain.gsoft.com.au> (doconnor@gsoft.com.au) Subject: Re: File I/O in kernel land (was: Re: 2nd warning: 2.2.6 BETA begins in 10 days!) From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199801270651.RAA29592@cain.gsoft.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk >> My real concern is holding on to lots of dynamically allocated kernel >> memory, which is something I can't see getting around without the >> screen saver doing file I/O. In Linux, dynamic kernel memory was a >> precious resource. Is it not so in FreeBSD? > Umm, well wouldn't it be allocated in either case? > You either load it in the kernel, or you load it in user land, and > then copy it to the kernel.. You still take kernel memory to do it. In Linux (when I was hacking it), dynamically allocated kernel memory was on the `very precious' scale, as opposed to statically allocated memory, which was on the `precious' scale. My point was that without having the size of the image ahead of time, then you would always need to dynamically allocate memory, and I was looking for a way to use the vnode instead, and let the I/O subsystem buffer everything as needed. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped