> | That is a _great_ source of entropy. 
> So are disk and network accesses, I don't see harvesting code being
> sprinkled inside them. Probably because more people would scream if their
> network or disk performance died.

Those are on their way.

> | Please explain "ill advised".
> Your system will suffer so badly that 
> a) You will lose serial interrupts when using X
> b) You will not be able to use your sound card with acceptable performance
> c) If you use an ATAPI cdrom you will get device timeouts;
>    acd0: READ_BIG command timeout - resetting
>    ata0: resetting devices .. ata0: mask=01 ostat0=58 ostat2=00
> interactive use of -current will be so poor as to be useless.

The dev/random inderatction here is a _symptom_ of the problem; any other kernel
thread would have a similar problem.

But I think we are arguing semantics.

> | Why? The rest of the kernel has not had the Giant mutex properly
> | degraded/removed/unravelled, and this is the real problem.
> Well this would indicate that having the current random module is probably
> a little premature then. Perhaps we should back it out completely until the
> Giant mutices are gone.

Arguing for this is the same as arguing for removal of any code that is not
inside Giant. ie, it makes no sense.

As I have said before, I am working on certain tweaks to improve the

In the meanwhile, this is CURRENT, please be patient, there are worse
problems. (Try "tar xzf VERYBIGFILE.tar.gz" sometime and watch your system

> | Later, when the Giant unravelling progresses, you can remove that.
> I'm asking for an non-default flag/option to turn off the harvesting
> inside syscons until then. A sysctl would be good.

What's wrong with a private patch?

> But if I want that randomness I can't actually use the machine to use ssh.
> I don't think turning my machine into a single-purpose graphical entropy 
> provider is really that acceptable.

Sounds to me like you need STABLE, not CURRENT.

> As to "good" ;
> /* NOTE NOTE NOTE - This is not finished! It will supply numbers, but
>  *                  it is not yet cryptographically secure!!
>  */
> That's your comment isn't it?


> If you're only harvesting from the keyboard and mouse then you are
> in trouble for headless servers. 


> Most things that require really strong random numbers are network connected 
> in some way, so perhaps the harvesting should be focussed more on network 
> interfaces where it makes more sense, rather than relying on localised
> human intervention.

Correct. On its way, as I have said may times.

> Look I know you wrote it, and I know you took heat for it. Perhaps
> you should back off a bit and have a little objectivity here. I don't want
> to get rid of the random module, I want to reduce the impact it has on
> my machine when I'm using it interactively, and that's my choice.

Help me then. Patches would be useful. Screaming for backout is not.
Understanding SMPng is paramount.

> Given the number of unanswered emails about hwptr went backwards there's
> a lot of people who run current and might also like that choice.

There is no direct cause->effect here from the random device to that
problem. The reandom device is a busy thread outside Giant. *ANY* thread
will do that. There are lots of that kind of thing doing that in the kernel
ATM, and they all need to be fixed.

Mark Murray
Join the anti-SPAM movement: http://www.cauce.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to