Re: kill -9 <pid of X>

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


On Wed, 12 Aug 1998, Olaf Titz wrote:

> > But sooth! Look at fbcon! Critical sections are not a problem
> > because the drivers are in the kernel and are not tasks, subject to
> > signals and scheduling. Maintaining coherent state is not a problem,
> > because of the same reasons. No special permissions are needed, because
> > the code is a kernel device driver. VT switching coordination is not an
> > issue, because that is handled elsewhere. Everything just works right
>
> You're right wrt. stability, but this driver can't use accelerator
> functions of the graphics card, or the whole can of worms opens again,
> right?

Wrong. Well, it depends on how you make the accels available to
userspace. If you just mmap the registers you lose stability again, but
if you wrap the accels in ioctls you can ensure stability that way.

> Not using things like bitblt ops of even so simple chips as
> CLGD5426 (not to mention state of the art hardware like Millennium II
> etc.) would be a shameful waste, IMHO.

Yes. But you can implement your own ioctls in fbcon drivers, so
each driver can export all of its acceleration capabilities that way. The
userspace app just needs to be aware of what ioctls go with what drivers.

> So we really need some control over the kernel, but I suspect for that
> signal blocking and RT scheduling is enough. I don't know whether this
> can be done with the current X server implementations, though.

I assume that signal blocking would happen in the kernel. If so,
the current X servers should not need to be changed.

> The only nagging issue is signal 9 which can't be blocked. (Give root
> the special privilege of blocking signal 9?)

Maybe these capabilities could be used for this purpose.

> Or is it always safe to
> interrupt a graphics accelerator function? I think not.

No it is not safe to do this.

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