random(4) plugin infrastructure for mulitple RNG in a modular fashion

[Warner Losh]

On Aug 8, 2013, at 8:23 AM, John Baldwin wrote:

> On Wednesday, August 07, 2013 4:20:29 pm Peter Wemm wrote:
>> On Wed, Aug 7, 2013 at 12:27 PM, Steve Kargl
>> <sgk at troutmask.apl.washington.edu> wrote:
>>> On Wed, Aug 07, 2013 at 11:28:58AM -0700, David O'Brien wrote:
>>>> 
>>>> * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG"
>>>>  option.  The files sha2.c, hash.c, randomdev_soft.c and yarrow.c
>>>>  comprise yarrow.  random(4) device doesn't really depend on
>>>>  rijndael-*.  Yarrow, however, does.
>>>> 
>>>> * If the kernel doesn't have any random_adaptor adapters present then
>>>>  the creation of /dev/random is postponed until next random_adaptor
>>>>   is kldload'ed.
>>> 
>>> My kernel config files have included the following 2 lines for
>>> ages:
>>> 
>>> makeoptions  NO_MODULES
>>> device       random
>>> 
>>> If I try to build a new kernel under your scheme, will the
>>> build die with an error about a missing option?  If the answer
>>> is 'no', then the yarrow adaptor should be opt-out.
>> 
>> That's the main point here.
>> 
>> If I'm running on a working system, I have a reasonable expectation
>> that the kernel config I was using yesterday will work sufficiently
>> tomorrow that I won't get hosed by doing a 'svn update && make
>> buildkernel && make installkernel'.
>> 
>> If that's not the case and there is a required change in order to not
>> hose your system then POLA dictates that not making the required
>> changes causes a build failure.
>> 
>> There's more leeway on head than a stable branch, but remember that
>> when people upgrade from 9.x to 10.x they tend to take their 9.x
>> kernel configs and make whatever changes are needed to get it to
>> build.  The 9-stable -> 10-release config path needs to catch fatal
>> errors like this at build time.
>> 
>> Patching GENERIC isn't a complete solution.  It doesn't solve the
>> 'yesterday it worked, today it's a brick' problem.
> 
> The counter to this is that in the recent past, any suggestion to add anything
> to DEFAULTS was met with "that's the wrong way".  In actual fact, changes
> to GENERIC happen quite often, and we often break older kernel configs from
> older branches (ATA_CAM is no longer in 10 for example).  I'm not sure I buy 
> the argument that we can never break kernel configs from older branches.
> 
> I also think that NO_FOO options aren't the way to go and that we should 
> always create "positive" options, but add them to GENERIC when making a 
> previously standard thing optional.  I think adding things to DEFAULTS should 
> be rarely done, if ever.

For the embedded kernels, where std.* take the place of the sledge-hammer DEFAULTS, they are often the right place to put options that will be the same for all kernels due to hardware constraints or dictations. In this case, the port maintainers would know if there's a hardware RNG or not on the chip, and if not put it into the appropriate std.foo file.

Of course, the fail stupid part of this patch is an even more fundamental flaw in this patch, but I digress...

Warner

Warner