Xorg input thread (2)

[Tiago Vignatti]

Keith Packard escreveu:
> On Tue, 2007-07-17 at 22:15 -0300, Tiago Vignatti wrote:
> 
>> Well, my attempt to do this 
>> statically failed.
> 
> Hmm. Last time I did this, it didn't seem *that* hard; tracing the code
> from the mouse device input function through the event queuing code and
> off to the cursor update functions. The thing is, getting it 'wrong'
> only means paging occasionally, which isn't fatal, and can easily be
> fixed after the fact.
> 

Okay, I surrendered to the statically one.

Please, correct me if I'm wrong, but what I did was to put a breakpoint 
on mouse device function using the debugger and traced all the path 
until the cursor updates on the screen. Then I'm seeing each data and 
function that it path touches, putting them on the separate memory 
region (section) and locking it on the physical memory. This path comes 
from the server, goes to the DDX input driver and finishes in video 
driver. Am I right?

Well, but now the problem is another one. To put the data and code 
inside the section I'm using that GCC attributes mentioned by Jesse. The 
problem is that the attribute method only sees global symbols and we 
have a lot of local and dynamic variables on the server code. So could 
you, linker scripts experts, tell how to do this? I want to put (or 
allocate) in a separate section the dynamic variables (that which lives 
on the heap) to so then mlock this section. Any hint? A linker script 
does this easily?


> In particular, the code shouldn't be calling *any* libc functions, or
> things like xalloc/xfree as those are not re-entrant from even a signal
> handler. If you're tracing a path like that, we've already lost as you
> can't use the non-threaded C library if that's happening.

humm... errr... ahmm... Keith, forget it. It was my mistake ;)


-- 
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br