Xorg input thread (2)
vignatti at c3sl.ufpr.br
Wed Jul 18 20:06:54 PDT 2007
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 ;)
C3SL - Centro de Computação Científica e Software Livre
More information about the xorg