|
|
2011-03-30
, 04:58
|
|
Posts: 2,014 |
Thanked: 1,581 times |
Joined on Sep 2009
|
#32
|
|
|
2011-03-30
, 07:04
|
|
|
Posts: 4,365 |
Thanked: 2,466 times |
Joined on Jan 2010
@ Australia Mate
|
#33
|
|
|
2011-03-30
, 14:22
|
|
|
Posts: 4,365 |
Thanked: 2,466 times |
Joined on Jan 2010
@ Australia Mate
|
#34
|
|
|
2011-03-31
, 00:08
|
|
Posts: 63 |
Thanked: 26 times |
Joined on Jul 2010
@ Canada
|
#36
|
Short answer: no, it won't work.
Long answer: I tried that at first (actually, a slightly more complex version of that; you can see the remnants of it in mlocker.c). The problem is that those processes aren't actually standalone binaries. The file you mention is just a symlink to maemo-invoker. maemo-invoker, in turn, talks to maemo-loader (a daemon), telling it "please run the rtcom-call-ui application". maemo-loader then opens up /usr/bin/rtcom-call-ui.launch and executes it. Only here's the rub, and why all the hassle with maemo-loader in the first place: the .launch files aren't actually executables. Oh, they're binaries, to be sure, but they're more like shared libraries with a main function. maemo-loader loads them and transfers control over to them without ever calling exec().
You can do an ls -l /proc/*/exe to see just how many processes are running with maemo-loader as their system-recognized primary executable. So, whatever hacks I'm going to do, they'll have to be more complex and target maemo-loader itself. I certainly plan to, at some point; might even throw a renice() in there too. It'd sure be keen if all the processes on the critical path didn't have to wait for page faults or processor scheduling when you get a phone call.
|
|
2011-03-31
, 00:50
|
|
|
Posts: 4,365 |
Thanked: 2,466 times |
Joined on Jan 2010
@ Australia Mate
|
#37
|
|
|
2012-01-09
, 22:05
|
|
Posts: 43 |
Thanked: 18 times |
Joined on May 2010
@ Sydney
|
#38
|
N9 / N900 Youtube Videos
N9 "Faster, Darker, Better" Theme Pack
---
www.F2thaK.com