mobi phil <m...@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...
