lkml.org 
[lkml]   [1998]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: getting rid of iopl(3) in XFree86
Date
From

Mingo wrote:

> 2) a kernel-based cli/sti implementation. {=new syscall or ioctl, root can
> 'switch' into cli/sti mode, and this capability remains even after we have
> dropped root priviledges. A thread in cli/sti mode can call the
> kernel-based sys_cli() and sys_sti() functions, even when not in iopl(3)
> mode}. cli/sti is rarely used in XFree86, mostly used during mode switch

As long as it remains rarely used. There seems to be a
lot of very bad graphics hardware out there, if recent
threads here are to be believed.

> (some cards are volatile beasts). cli/sti is already virtualized within X,
> so it's about a 10 lines hack to support Linux's kernel-based cli/sti ...

Does the program doing the cli/sti syscall need to be
mlocked down? I think it probably does. This seems to rule
out that program being the X server, since the X server is
too huge to lock down. It could be a small X server helper.

This X server helper could be the same program as the
one suggested by Linus. It should be small and simple
and handle only mode changes. It can restore modes if
the X server crashes. (The question is how much it needs
to know. If it needs to follow _all_ the programming of
the graphics card in order to be able to restore state
at any time, then there is a major context switching
performance problem.)

Even with syscall-based cli/sti, I think that my proglet
suggestion (see the thread 'minimal kernel support for
user-space graphics drivers') is necessary in order
to handle interrupts being fed to user programs in the
presence of interrupt sharing. As far as I know there is
no generic way for the kernel to find out which card did
the interrupt. It has to ask the driver. And that part of
the driver needs to be in the kernel.

Given a proglet capability, you don't really need a
syscall for cli/sti, because you can have cli/sti as
proglet commands that execute in the kernel. This also
avoids ugh/mlock problems.

--
Erik Corry erik@arbat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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