From owner-cvs-all Wed Jun 30 11: 6:13 1999 Delivered-To: cvs-all@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 579B7155AB; Wed, 30 Jun 1999 11:06:09 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id UAA43776; Wed, 30 Jun 1999 20:04:34 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Brian F. Feldman" Cc: Julian Elischer , Garrett Wollman , Peter Wemm , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern init_main.c kern_fork.c kern_linker.c vfs_aio.c src/sys/sys proc.h In-reply-to: Your message of "Wed, 30 Jun 1999 13:58:03 EDT." Date: Wed, 30 Jun 1999 20:04:33 +0200 Message-ID: <43774.930765873@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk In message , "Bria n F. Feldman" writes: >I thought about this a LOT, and it's not a great idea to hold a pointer to >the proc... It's not really that different from doing it to a vnode... Mind you, I've been trying to find a way NOT to do it for vnodes because I would like to be able to free them again. And I'm a little bit concerned if the zone allocator never frees pages again because that means that one mistake with a fork(2) and a lot of RAM (not VM, actual RAM) is tied up until next reboot. So if we have decided to make struct proc a stable storage kind of thing, then holding pointers is perfectly ok (with the addition of a serial number, p_pid wont do). It is the move to stable storage that has me concerned. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message