Date: Thu, 3 Dec 1998 13:11:05 +1100 From: David Dawes <dawes@rf900.physics.usyd.edu.au> To: Mike Smith <mike@smith.net.au> Cc: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>, current@FreeBSD.ORG Subject: Re: sio breakage Message-ID: <19981203131105.F2934@rf900.physics.usyd.edu.au> In-Reply-To: <199812030107.RAA01213@dingo.cdrom.com>; from Mike Smith on Wed, Dec 02, 1998 at 05:07:00PM -0800 References: <19981203115222.A3051@rf900.physics.usyd.edu.au> <199812030107.RAA01213@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 02, 1998 at 05:07:00PM -0800, Mike Smith wrote: >> On Wed, Dec 02, 1998 at 08:46:45PM +1100, Peter Jeremy wrote: >> >> >>> I don't believe this is reasonable. We should provide some safe way >> >>> for an application program to execute code with interrupts disabled. >> >>> Amongst other applications, XFree86 needs this. >> >> >> >>It shouldn't (ideally). >> >I agree. And whilst I haven't checked why, XFree86 does appear to >> >disable interrupts at times. >> >> I agree too, but it does disable interrupts when probing for fixed pixel >> clocks (which is mostly only done for obsolete hardware), and sometimes >> when programming PLLs. If someone has a better way of handling time >> critical thing like this (preferably in a portable way), please let me >> know. I'd love to dump our disable interrupt code. > >I get the impression from this though that you only do interrupt >disables when probing or changing video modes, is that correct? Yes that's true (modulo any bugs). >The entire train of angst here is descended from percieved problems in >interrupt delivery during normal operation; if you're only disabling >interrupts during startup then this prettymuch exonerates the X server. > >> >> If it does, this is clearly indicative of a >> >>need to move some of the server code into the kernel, >> >You mean, like GGI <http://www.ggi-project.org/>; :-). >> >> There are some tasks that are much better suited to the kernel, and >> perhaps a better balance could be found by just doing those few selected >> things in the kernel and leaving the rest of it in user space. > >Quite possibly; I wasn't sure that it would help performance, and it >would *certainly* make your lives harder. 8( I'm thinking first of all of the cases where the X server currently disables interrupts, which are areas that don't affect performance. Clock probing is close to redundant for modern hardware, but there are still time-critical issues when programming some PLLs, and that might be more reliably done in the kernel. It would make our lives harder, yes, and maybe it isn't really practical given the range of platforms that XFree86 runs on. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981203131105.F2934>