sysint, emergency application
Timo Juhani Lindfors
timo.lindfors at iki.fi
Wed Apr 14 00:18:10 CEST 2010
mobi phil <mobi at mobiphil.com> writes:
> I proposed earlier something I would call "sysint", and I am more and more
> convinced that this would be very useful for everybody. It would be a
> special kernel to userspace call, where the kernel would launch special
I don't think modifying the kernel is the answer. You can already use
ulimit to limit the resource usage of non-important processes. Your
challenge is to make the userland applications work nicely with this.
> application to handle events like phone call, keyboard pressed longer etc,
> etc. If the gsm driver would detect a gsm event (do not know how it is
There is no gsm driver in kernel. It's just a serial port.
> handled inside the kernel exactly) it would "freeze" anything else, and
> would call our sysint application to handle the incoming call. Such an
> application would be very small, would just show a number, or would do fast
> lookup in a database with phonenumber etc. The same sysint application could
> be used for "killing" non responsive applications, or sturting GUI
> subsystems. This could be triggered if one of the buttons are pressed longer
> than 5 seconds etc.
I have had the same idea. However, to me it was enough that I can
always _answer_ calls. If there's a problem I can easily delay
outgoing calls a bit.
On my system hitting the AUX button always answers a call, regarless
of how broken X is.
> Under heavy load dbus and other userspace tricks are
I completely agree. Unfortunately, most of the GSM userland stuff is
> just not enough good in my opinion. I would like to have both qtmoko and
> enlightment based gui in the same time, but I do not have a "master"
> gui/applicaion to switch between them. etc. Such a master application could
> start also other "gui subsytem" based applications like directfb, sdl etc.
Unfortunately switching virtual consoles in unstable. So you might
just introduce more unstability...
More information about the openmoko-kernel