> | 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
situation.

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

> | 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?

Yes.

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

Correct.

> 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.

M
--
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