Date: Thu, 07 Dec 2000 11:38:11 -0800 From: Kirk McKusick <mckusick@mckusick.com> To: arch@freebsd.org Subject: Getting Kernel Process Information Message-ID: <200012071938.LAA03622@beastie.mckusick.com>
next in thread | raw e-mail | index | archive | help
For the third time in a week, I got the following message when I
tried to run ps on my 5.X system:
proc size mismatch (39776 total, 1136 chunks)
This message arises when the size of the proc structure changes.
With the current SMP development, the proc structure changes at
a very high rate of speed. The current kinfo_proc interface used
between the kernel and user processes is built from two pieces:
struct kinfo_proc {
struct proc kp_proc;
struct eproc kp_eproc;
}
Kinfo_proc contains a copy of the kernel's proc structure
followed by an `extended' proc structure which has lots
of bits and pieces that have moved out of the proc structure
or are otherwise needed. Any change to the kernel's version
of the proc structure changes the size of the kinfo_proc
structure and hence causes a mismatch when attempts are made
to copy it out.
I propose to change the kinfo_proc structure. The new
kinfo_proc structure will contain only the stylized `extended'
proc structure which will be augmented with the twenty
fields that are actually referenced from the proc structure
by user processes. By taking this approach, changes to the
proc structure will not affect the format or size of the
kinfo_proc structure returned to user processes. The new
`extended' proc structure will have plenty of spare fields
added to its end so that when new fields are added to the
proc structure that user-level processes need/want to know
about, they can be added without changing the size of the
exported kinfo_proc structure and thus will not require
recompilation of the dozen or so programs that use the
exported interface. Note that even if 200 spare bytes are
added to the kinfo_proc structure, it will still be smaller
than the current one.
Note that I am proposing to make this change only in the
5.X tree. I am not proposing that it be back ported to the
4.X tree.
I am not interested in starting a long discussion on all
the possible alternatives for exporting kernel information
to user processes. I recognize that there are better ways
to handle these issues. I am just trying to make an
incremental change that is small in scope and hopefully
will make an annoying problem significantly less common.
With this caveat, comments are solicited.
Kirk McKusick
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?200012071938.LAA03622>