> | Screaming for backout is not.
> I wasn't screaming for a backout, I asked for a way to turn off harvesting
> from the mouse code. You're the one that started in, I just responded in
> the same condescending manner you used with me.

If I was condescending, then I apologise.

I am somewhat frustrated, however, at the apparrent (general) lack
of understanding that is going into this discussion.

If I was to provide a hackaround for everything that I am working to fix,
then that is _all_ I'd do, and undoing them afterwards would be a nightmare.

> | 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
> That is simply not true. Code was inserted into the sycons and pcvt code
> and that's the code in question. Removal of this code doesn't directly
> effect the random device either by your argument, in which case you
> shouldn't have an objection.

Let me rephrase the critical part of that chain; the problem is _any_
busy kernel thread. Today its random, tomorrow who knows. Detangle
Giant, it all goes away.

Optimise the harvester, it becomes less noticable. This is on its way.

> | will do that. There are lots of that kind of thing doing that in the kernel
> | ATM, and they all need to be fixed.
> Yeah but if I move my mouse I want interactivity and responsiveness, if I'm 
> untarring a 200Mb file I'm willing to live with the consequences. These are
> choices. It's wrong to be able to cripple a machine by moving the mouse,
> and I think its wrong that code with that large an impact doesn't have
> the option of being turned off.

Its also wrong to fix problems the wrong way.

I'm working on a correct fix, and you have a workaround.

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