Messages in this thread | | | Subject | Re: getting rid of iopl(3) in XFree86 | Date | Sun, 29 Mar 1998 16:18:00 +0200 (MEST) | From | (Erik Corry) |
| |
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
| |