(This was originally a response to
Mark Lord's post in the thread "Compiling userland apps into kernel?", but became too off topic and unwieldy for that thread. It's mainly intended for someone considering writing the program Mark describes below. I'll try to answer questions regarding my implementation (from memory) next time I hit a European internet café. Sorry it's kinda long.)
Mark:
OR.. you could tackle a project that has been needed for about 6 months or so: I need somebody to figure out (code & test) a kernel function to launch a userland command line, and wait (non-blocking poll) for it to exit, and retrieve the exit status. Given that functionality, we could turn the whole thing around, and have Hijack launch the apps on-demand (menu item selected), using config.ini to bind menu entries to userland command lines.
/me administers slap to face for coding 85% of this and not finishing it or releasing the code.
It actually wasn't even that hard. (Actually, looking back on it, it was a pretty large undertaking for a linux/C newbie, but it's hard to classify something I enjoyed so much as hard work.) I just saw the need for it (and personally wanted it) and taught myself everything I needed to know to implement it (from linux web resources, the K&R, and selected reading from "Advanced Programming in the Unix Environment". Oh, and some unix programming newsgroup that was very helpful.) (I had little previous knowledge of Linux or C besides a firm grounding in programming (including C++) and scant unix use.)
Ironically, it was these few weeks of hardcore programming that so thoroughly delayed the project. I used my new knowledge to get an awesome linux programming job that was 40+ hours a week (I frequently worked more than 40 hours a week for free, because they were paying me too much) that more-than-quenched my desire to program, even for this project that I was thoroughly enjoying.
The obvious question follows: why didn't I turn the project over to someone else or release the source? Well, rather selfishly, I wanted the credit for the project and kept telling myself I'd find time to finish it that weekend. Then, rather suddenly, I decided that this was the best summer to explore Europe because summer jobs tend to only become more important as one nears the time they will permanently enter the workforce. So I quit my job (another self-administered slap to the face) (even after they offered to double my already ridiculous hourly pay to stay. Additional slap.) to backpack around Europe for about 5 weeks. (Unbelievably cool-- de-slap, de-slap. Also see off topic post on europe trip.)
I had always intended to clean up and release the source if I was obvious that I couldn't finish it in the short term, but I was so busy getting my projects at work together (they were none to pleased at my sudden departure) that this slipped my mind. Now, I have no access to the code until August 8 at the earliest, even to forward it to someone.
Anyway, I'd recommend anyone who wants this functionality before late August to write it themselves. My project was intended mainly for my personal use anyway. I do, however, promise to finish it in August when I get back (perhaps it can / should be kernel-integrated).
Currently, I think there was one semi-important bug where it incorrectly thought programs that had finished / been terminated were still running. [edit: I also wanted to see about more effective methods to track programs that intentionally change the process group of their children (needed to SIGINT many daemon-type programs, see below.)] Also to-be-addressed are user interface improvement and source code cleaning (as I wrote the thing I was constantly finding / learning ways to do things more efficiently, and thus the source is currently rather haphazard.)
The way it works is pretty simple. You attach it to your init and it loads this (relatively small) program on every boot. When selected from the hijack menu, it brings up a list of preset programs with menu titles if it finds a specific config file. You also always have the option of browsing the directory structure for executable programs as well. When a program is selected it is run in the background (in its own process group). You then have the option of SIGINTing any of the process groups that you've started. (For the uninitiated, that means asking a program you've started to close itself.)
So basically, the 1 out of 30 boots you want to run emptriv you tell emptriv to start then select it from the hijack menu. When you want to free the RAM it was using you can close it. This has the important benefit of not having to spend the time and (more importantly) RAM loading every program on each boot that you might only occasionally use.
Mark was very cooperative adding the necessary things to hijack to get this to work. (I remember there being one more thing I wanted added to hijack, but it was small and I forgot what it was.)
Aside: In addition to this program, I had taken a break (short attention span) to turn the rather-nice (IMHO) directory browsing code into something that could be incorporated into someone else's code, and after I did that, it seemed rather trivial at the time to implement a text file browser. (The word wrap, font / line spacing changing, scrolling and some other stuff took longer to implement than I thought it would, but is now pretty much done.) This code is about 90% complete, but fell victim to the same problems as the other did. (After almost finishing this, I found another, slightly simpler implementation of it on riocar.org, but still plan to finish this one.) (Nested aside: it also seems pretty easy to implement cellphone-style editing of files via the remote but this is a ways off. (This also requires temporary remounting of the drives RW in the car / wherever for file saving which I have not looked into.) I'd like to use this for in car script editing and to-do lists / notes (Doug (I think?) wanted this implemented, as I recall.) This phase of the project is a ways off.)
So anyway, that's the current state of my empeg programming adventure. For anyone considering something like it, I highly recommend it (although perhaps in a more responsible manner.) It's one hell of a good time. Feel free to ask me questions, but I'll only have sporadic internet access. I'm still recovering from this rather idiotic experience where I was nearly trampled / gored by 6 large bulls, six large steer, and numerous smaller (as in around 600-800 pounds kind of smaller) bulls.
For those more cosmopolitan than I, feel free to suggest good European travel destinations in the off topic thread I'm about to start.
In the (current) native tongue,
Hasta luego,
John