From owner-freebsd-hackers Sun Jan 21 04:30:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA14297 for hackers-outgoing; Sun, 21 Jan 1996 04:30:01 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA14265 for ; Sun, 21 Jan 1996 04:29:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id EAA12380 for ; Sun, 21 Jan 1996 04:30:00 -0800 Message-Id: <199601211230.EAA12380@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: hackers@freebsd.org Subject: "u" struct and -current From: David Greenman Reply-To: davidg@Root.COM Date: Sun, 21 Jan 1996 04:30:00 -0800 Sender: owner-hackers@freebsd.org Precedence: bulk If you haven't noticed already, reading the user struct via procfs is currently broken in -current. This apparantly happened when John changed the way that the upages (u page + kernel stack) are allocated. I was looking at fixing it, but then had another thought: The user struct really should just go away. The PCB and any other needed parts of struct user should be moved into the proc structure. It was originally seperated in an attempt to squeeze a few extra bytes out of the system when the process was swapped out...but this is silly because on any reasonable machine that has a fairly large page size, it ends up wasting about 10 times more memory than it saves (because non-swapped processes use a whole page to store about 400 bytes). I think struct kinfo_proc can go away completely and the rest is perhaps 100- 200 bytes at most. Those things which ps/w/top were getting by reading struct user will have to be changed to get the information via reads of /dev/kmem, or even better, via sysctl. If we do this there is an added bonus of easily allowing an unmapped page just below the process's kernel stack which will make trapping stack overflows easier. Currently, stack overflows will overflow into the user struct (clobbering it) and perhaps more before finally hitting an unmapped page and causing a panic. Comments? Have I overlooked something? -DG David Greenman Core Team/Principal Architect, The FreeBSD Project