lkml.org 
[lkml]   [2005]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Xterm Hangs - Possible scheduler defect?
Chad N. Tindel wrote:

>>I personally like the linux way: "root has the ability to shoot himself
>>in the foot if he wants to". This is my computer, damn it, I am the one
>>who tells it what to do.

> I'm all for allowing people to shoot themselves in the foot. That doesn't
> mean that it is OK for a single userspace thread to mess up a 64-way box.

If root has explicitly stated that the thread in question is the highest
priority thing on the entire machine, why would it not be okay. The
fact that root made a mistake is the issue here, not that the system
didn't protect itself.

>>This is much, much better than the "users are stupid, we must protect
>>them from themselves" kind of way that other OS'es use.

> Isn't this what the kernel attempts to do in many other places? What else
> could possibly be the point of sending SIGSEGV and causing applications
> to dump core when they make a mistake referencing memory? Isn't it the
> kernel's job to protect one application from another?

Yes. But at the same time, if root wants to do something, the kernel
should let them. There are many, many ways that root could trash the
system. "cat /dev/urandom > /dev/kcore" would do quite nicely.

> I see what you're saying about the swap daemon. How about if I make my
> statement less black and white. Some kernel threads should always have
> priority over userspace.

Not necessarily. The latest latency-reduction patches allow root to
specify exactly what the priorities should be.

> I believe the mindset required for a home system that is doing audio recordings
> is different than the one for enterprise-level systems. How do we unify
> the two?

There are professionals who use linux for audio as well, it's not just
home systems. That said, you unify them with reasonable defaults, and
the ability for root to override them.

Chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.107 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site