sysint, emergency application

[Timo Juhani Lindfors]

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
dbus-only.

> 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...