>> Unless you can somehow invent a handle that the snapshot call can
>> pass back to the process, [...]...at which point it seems to me you
>> might as well call that handle a file descriptor and go with kernfs
>> and/or procfs, since sysctl is already hopeless on kernel corpses.

> Ok sure.  But then you have to make sure kernfs and/or procfs is
> mounted.  That sucks.  You shouldn't need that.

Mmm.  Yeah.

> Hey.  I think I just convinced myself that this should use a special
> type of socket.  (argh, I wish I could remember who suggested that,
> or what list it was on.)

I think I said something of the sort, but don't recall which list.

The point someone made (I saw the message but don't find it at ready
hand now) about storing tens of KB of snapshot on an AF_KINFO socket is
a good point - though it's easy enough to store tens of KB of stuff on
AF_INET sockets, so I'm not sure how real the danger is.

How about this: do a recv() and you get a struct iovec dropped into
your buffer.  This iovec describes a piece of memory which the kernel
has just created for you, as if via MAP_ANON mmap() with a nil first
argument, which contains the data in question.

No two-call snapshot-and-read paradigm necessary, and it can handle
comparatively large amounts of data without any problem.  The downside
is you have to remember to munmap() the buffer when you're done; I
don't consider this a big disadvantage.  Oh, and if you're really tight
on swap it may fail....

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B