> In article <Pine.HPP.3.91.980811192452.22974F-100000@gaia.ecs.csus.edu>,
> Jon M. Taylor <taylorj@ecs.csus.edu> wrote:
> >>
> >> That's not the kernel's job.
> >
> > Whose job is it then? X's? X cannot do the job properly because
> >it can be killed and leave the hardware in an unknown state.
>
> Jon, why do you continue to maintain this, when you have been told that
> you're wrong?
I have not.
> The X server can avoid even kill -9 from a normal user. As it stands,
> it doesn't do that, and I personally think it's a bug in X.
I agree.
> But it's
> not a kernel problem - X could make sure (by doing a "setuid(0)" to
> renounce all use privileges) that nobody can kill it but root.
>
> (And by the time you have a root that sends it a signal, you have a root
> that could have killed the machine in easier ways, so don't even bother
> claiming that it makes any difference).
But I wasn't trying to kill the machine. I was trying to make the
X server hang up in a way that is supposed to work correctly.
> So "that's not the kernel's job" is correct.
I stand by my claim. If userspace cannot, by its nature, properly
guarantee the atomicity of those critical sections, video card programming
cannot be done properly in userspace. Thus, it *is* the kernel's job.
> As long as you continue to claim this stupid "oh, the X server can't do
> this, because.." when it's very obvious that the X server _can_ do it,
> you aren't very believeable.
Sorry. It cannot "do it" correctly in userspace. I'll buy
trusting the X server, you convinced me of that. I will NOT buy the X
server being unable to handle signal 9 correctly.
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