Re: kill -9 <pid of X>

Jon M. Taylor (taylorj@ecs.csus.edu)
Wed, 12 Aug 1998 15:47:01 -0700 (PDT)


On Wed, 12 Aug 1998, Brandon S. Allbery KF8NH wrote:

> In message <m0z6d1t-000aNFC@the-village.bc.nu>, Alan Cox writes:
> +-----
> | Or the kernel decided to blow it away, or I fed it stuff that crashed it
> | solidly. There are many ways to upset the Xserver. (Thats not entirely
> | an argument against any specific setup btw - no doubt kernel code would
> | have some upset potential too)
> +--->8
>
> "Some"? Is wedging the console less preferable than wedging thwe entire
> system? I know where I can get NT4 in that case :-)

Suppose the sounds driver locks up and wedges your system that
way. Better put in in usersapce too. After all, you aare a lot better
off losing your sound capabilities than your display, right? Yet I don't
see you railing against the evil destabilizing influence that is kernel
sound card support. Or mouse drivers, or the parport driver, or a couple
dozen other in-kernel drivers.

> Yes, there are problems with the current setup. No, moving graphics into
> the kernel isn't an answer: it's just a good way to turn a small problem
> into a much bigger one.

Funny. From where I (as someone who works with kernel graphics
every day and has done so for most of the past three years) sit, those
stability problems just aren't there. When bugs do occur, they are easier
to track down and fix. Also, the drivers aren't also controlling the
keyboard in RAW mode, so if the driver does bomb I might actually be able
to SAK or switch to another VC and either reinsert the driver or cleanly
reboot the system.

When a KGI or fbcon driver breaks, I get a nice oops trace on the
screen, and if the screen is hosed I still get it in my syslog. When X
breaks, God only knows where the problem occured. It might not have even
occured in the video driver code itself, since X is so monolithic. In any
case, I'll get no oops trace from X. If I am lucky and all of X didn't
die, I might be able to switch away, but there will be no SAK for me. I
either try re-running X or reboot.

All code breaks. Driver code is no exception. Be it in the
kernel or in userspace, the code must be fixed if it is broken. If it
breaks sooner and thus can be fixed sooner, it will break less in the
long run. Stability though userspace is no better than security through
obscurity. Both are false economies.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html