[Prev][Next][Index][Thread]
Re: random sources interface
Actually, that was not the interface I was talking about.
You've done a COMification of rndsource_t, which is an internal data
structure of the randomness module that I don't think anyone really needs
access to. The only way that data is exposed in NetBSD is for the RNDGET*
ioctls, which seem little (if ever) used. Anyway, to export the status
information it is probably best to just have a stats structure and a signal
COM call to fetch it. But that is part of the "top" interface to the
randomness module, which is not the interesting one to me. (That's just
the meat--in the oskit it's all about the gristle.)
The interfaces that are more structurally interesting are the "bottom"
interfaces for injecting randomness into the module from other modules that
are somehow in contact with reality. That's the part of the NetBSD
interface documented in rnd(9), which is just rnd_add_data/rnd_add_uint32.
The obvious COM adaptation of this is to have the main "bottom" setup
entry-point into the randomness module be the analog of rnd_attach_source.
It takes the name, type, and flags, and returns a new COM object on which
you can make the add_data/add_uint32 (or other variants, perhaps) calls.
(It would also make sense to be able to fetch the rndstat_t stats with
another call on this object.) The last COM release on that object would
detach the source from the randomness pool.
The "top" interface would be the single object per distinct randomness
pool. This is what would have the "attach_source" call to create the
callback objects used by each source of randomness. It would also have a
read call to extract entropy and a write call to inject "good" randomness,
which are the analog to reading and writing /dev/random. For the
/dev/urandom functionality you'd need an additional call or a flag argument
in the read call to indicate whether you're reading only good entropy. The
simplest thing would be just do a small new interface with these calls in
it (about like NetBSD's rndpool_t). To facilitate full and easy
integration into oskit kernels, the thing to do is to provide the
oskit_stream_t interface in two objects: one that is read-only and always
readable a la /dev/urandom; and one for reading/writing good entropy a la
/dev/random. Reading good entropy can need to block, so its read method
must return OSKIT_EWOULDBLOCK, and the good thing to do there is implement
the asyncio interface as well on that COM object. With that and some
existing (or simple to hack) COM adapters the top end plugs in like an
existing device into oskit kernels.
It might be easiest to plug everything together if you implement it like a
device driver, using the oskit_device_t interface as the one to extend into
a new "randomdev" with the attach_source and open_good/open_nonblocking calls.
So that was the boring part. The "bottom" interface part is what's more
interesting to me, and probably more mysterious to those not fully
indoctrinated into the oskit way. The new COM interface for this is quite
simple as I mentioned: it's just got to have the add_data call and some
handy variants like add_uint32. The tricky part is how the drivers decide
to ask for that COM object and then use it. The driver modules will do an
oskit_services_lookup on their `osenv object', which the host kernel
provides to give them all the oskit_osenv_* interfaces to memory and
hardware and the host's interrupt system and so on. This could be done
either directly with a new interface oskit_osenv_randompool or somesuch, or
the randomness pool could be a device found in the device registry the
driver glue code already uses.
Most of the oskit's device drivers are glue code around drivers from Linux
and BSD systems that have their own internal interfaces to randomness
pools. For the Linux block and Ethernet devices, most of the relevant code
is common in linux/dev/ or linux/shared/. The glue code that does the
device probes would do the attach_source calls. Block devices call
add_blkdev_randomness, so this would be implemented to find the COM object
from attach_source and call add_* on it.
Follow-Ups:
References: