On Sat, Apr 15, 2000 at 05:41:57PM -0500, erh@nimenees.com wrote:
> 	How about dropping the elemsize argument because it makes it to
> easy to add stuff to the structure.  Instead, have the kernel code, if
> compiled with support for previous versions of KERN_PROC2, know how big
> the structure should be and use that instead.  (keep track of each different
> struct and use the right one, with the obvious optimization for additions
> of elements)

I was actually going this route, for a while, but when I started to
write some proof-of-concept code for it, changed my mind...  The main
objection to it is that the kernel would need to know the sizes of
all the different types of structures, even though it wouldn't ever
really use the various compat structures in raw form.
switch (kinfo_proc_version) {
  case KINFO_PROC2_1:
	len = sizeof(struct kinfo_proc2_1);
	break;
  case KINFO_PROC2_2:
	len = sizeof(struct kinfo_proc2_2);
	break;
  &c.
}
for (i = 0; i < num_procs; i++)
{
	copyout(procs[i], out+i*len, len); /* or something */
}
Those 'len = ' assignments would be the only place the old structure
definitions would be used in the kernel, and even though this
probably isn't what the kernel routine would look like, I don't know
how to get around something like that 'switch' block.

> 	The idea here is that if it is a little more difficult to change
> the structure it is more likely to stay the same.

I agree that the structure shouldn't change if it can be avoided, but
that's strictly from the point of view of a userland developer, who
likes some degree of stasis in interfaces.  Ignoring that matter of
taste, there are *no consequences* to changing the structure with this
interface, except for the actual structure changes.  And if it's
considered necessary to change the structure, I think we should try to
make it easy to do so.

Anyway, it's taken three pages, but I've said my bit now...  Duke it
out with Simon. :-)
--aidan