svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random sy...

[Mark R V Murray]

CC’ing to original lists.

Kip’s problem has come to conclusion, and our final (private) email
is forwarded to the lists with permission.

It should be noted that Kip was importing CURRENT to a fork of
FreeBSD, and there was a potential merging problem that may have
caused a link failure.

M

> On 17 Jul 2015, at 23:14, K. Macy <kmacy at freebsd.org> wrote:
> 
> On Fri, Jul 17, 2015 at 3:01 PM, Mark R V Murray <markm at freebsd.org> wrote:
>> 
>>> On 17 Jul 2015, at 22:39, K. Macy <kmacy at freebsd.org> wrote:
>>> Like I said, the linking issue isn't a concern. My problem is that
>>> it's not booting because it hangs in an uninterruptible sleep in dd.
>>> In addition, I strongly disagree with a change that by default could
>>> adversely impact network performance.
>> 
>> I’ve agreed that the fact that it is uninterruptible is cause for
>> concern, and I’ve now coded but not tested or committed a fix.
>> 
> 
> Glad to hear it.
> 
>> The fact that RANDOM_DUMMY never unblocks is a feature not a bug.
> 
> I don't recall having suggested otherwise. Returning with no entropy
> would be undesirable. But as you now, presumably, realize - having the
> reader be unkillable as a result of this wait is highly undesirable.
> 
> 
>>> If you say that you've tested RANDOM_DUMMY and it works for you then I
>>> guess I'm on my own.
>> 
>> RANDOM_DUMMY is for folks who don’t want a CSPRNG. It sounds like you
>> need one.
> 
> Yes. I had already reached the obvious conclusion that enabling
> fortuna would have bypassed all this grief.
> 
> 
> Cheers.
> 
> -K
> 

-- 
Mark R V Murray