I may have stumbled on a small problem. However, I'm not kernel hacker,
but things just don't look right. Appears that the ioctl for RNDGETPOOL
isn't implemented the way <linux/random.h> way you would think. So the
end result is if you use the ioctl in the defined way then your program
SIGSEGV's. Course maybe I'm just reading things right, so I'm coming here.
>From <linux/random.h> we have:
/* Get the contents of the entropy pool. (Superuser only.) */
#define RNDGETPOOL _IOR( 'R', 0x02, int [2] )
Shouldn't that be returning an integer array with two entries?
I wasn't the person who added the IOR defines. That was done by someone
else who didn't check with me first. So don't blame me.... :-)
The pool is 128 bytes, per POOLWORDS. Why isn't POOLWORDS in
<linux/random.h>?
The RNDGETPOOL interface is carefully designed to be extensible no
matter what the random pool size is --- which is a good thing, because
in Linux 2.3 the random pool size is dynamically resizeable.
The way it works is something like a struct addr in the BSD sockets
interface. The base structure definition is as follows:
struct rand_pool_info {
int entropy_count;
int buf_size;
__u32 buf[0];
};
To properly access the RNDGETPOOL ioctl, a program must access it as
follows:
#define MAX_SIZE 3500
struct rand_pool_info *poolinfo;
poolinfo = malloc(MAX_SIZE);
if (!poolinfo)
... error checking
poolinfo->buf_size = MAX_SIZE - 2*sizeof(int);
ioctl(fd, RNDGETPOOL, poolinfo);
Before the ioctl, poolinfo->buf_size is set to the maximum size of the
random pool which the program is ready to accept.
After the ioctl, poolinfo->buf_size will be set the maximum of the
actual size of the random pool, and the previous poolinfo->buf_size, and
poolinfo->buf_size bytes in the buf[] array contain the entropy pool.
The problem is that there's no good way to express this interface using
the IOR encoding scheme. I would have preferred that random.h had
continued to use old ioctl numbers for the random device driver, but
someone who subscribed to the IOR/IORW religion changed the ioctl
numbers without conuslting me, but I'd rather not change the ioctl
numbers again.
So it's inconsistent with respect to the IOR encoding scheme. Oh,
well. Note that there really isn't any reason for any program to use
this ioctl anyway. It's basically there for my debugging purposes
only.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/