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