Hijack v303: exec=, exec_once=

Okay, Hijack v303 is out.

New in v303/v302 are the following:

-- support for the new "PrevVisual" buttoncode from the recent Bug-Blat, and a new VisualSeek function which can be mapped to a real Rio Remote button as follows:

[ir_translate]
Visual.L=Visual.L
Visual=VisualSeek

Once the v2 final software is released, everyone will be able to use this new buttoncode. But the ir_trans stuff above will work NOW, but only for Next-Visual..

-- support for "exec=" and "exec_once=" software start-up directives in the [hijack] section of config.ini. These can be used to start third-party app's on boot at player startup ("exec_once="), and on ANY player startup ("exec=").

Syntax is something like this:

[hijack]
exec_once=/bin/imaginaryapp ghouls=5 pills=77 "quoted strings work too\n"
exec=dd if=/proc/sys/kernel/panic of=/proc/sys/kernel/ctrl-alt-del

Note that the latter example above is the one I used to test this functionality.. it should result in a "0" in /proc/sys/kernel/ctrl-alt-del afterwards (try it!).

If a command returns a non-zero exit status, this is noted on the serial console (but nowhere else currently).

Hopefully this will make software installation somewhat simpler. I will eventually include support for adding programs to menus with a similar mechanism.

Cheers

I've been obsoleted! Yay!

These can be used to start third-party app's

Cool! So you must have worked through that executing from kernel space stuff.

ext3 enabled versions are now available.

-Mike

My dream has been answered! Bravo! How'd you pull that off, Mark?

Now, on to converting the GPSapp installation over from Preinit to Mark's new method. Anyone have any tips? For example, can I now put GPSapp in any folder on /drive0 if I wanted, and would it work? What would the entry look like in config.ini for that?

does exec_once execute before or after the player executes... apps like gpsapp require to be run before, if i recall.

At present, both "exec=" and "exec_once=" run during player startup: the player is paused when it reads config.ini, and Hijack takes over and does the "exec" things before allowing the player to continue.

-ml

so the main thing is this.... does the player app already lock the com port before the "exec=" and "exec_once=" lines are executed?

Dunno. But the read of config.ini is one of the very first things it does at startup, so it might be fine. Try it and let us know!

Another thing I'd like to know is if I should do GPSapp as an "exec" or as an "exec_once".

When GPSApp messes up, I'd love to be able to restart it with a simple "quit" from the player's main menu. If I put GPSapp in the "exec" line, would it work that way?

I'm curious about how you dealt with your original reservations about starting programs in kernel space. I'll probably try to sort through your new code when I get a chance, but a quick summary would be interesting...

John

I don't think I've had any reservations about starting programs from kernel space like this.. It's more a case of not previously knowing exactly how to do it.

I gave it a shot during Christmas 2001, but couldn't figure it out quickly enough then, and so wrote the web/ftp servers instead, and posted a plea for somebody else to tackle it.

Somebody else did give it a go, and I took their last work, simplified it a bit, and fixed a bug or three: thus what we have today!

Cheers

There is nothing in Hijack to kill off previously started programs, so I suspect GPSapp needs to be "exec_once=", as would just about any other program that uses this mechanism.

Cheers

Okay, thanks!

Another GPSApp question...

Included in the GPSApp distro is the program "INCAR", as well as a little file called M50GPSAPP that's used by preinit to do an "If Incar then run GPSAPP". Question is: That little file, is that an ordinary shell script? And if so, can Hijack's "exec_once" command run it?

And another question.

GPSApp seems to run OK from the Hijack method, but the following appears on the serial port:

hijack_exec("/drive0/var/gpsapp/gpsapp"), rc=255 (ERROR)

Does that really indicate an error? Because it seems to run fine.

If the "INCAR" thing is just checking for DC_POWER, then you can replace it completely with a config.ini hijack macro:

;@DC exec_once=/drive0/var/gpsapp/gpsapp

Yup, that's brilliant. Of couse! (/me smacks self in forehead)

The '255' is the exit status returned by the GPS app, which in reality was probably "-1". I suppose one could look at the source code for GPSapp to see what it normally returns (or "exit()"s) after it starts up and spawns a daemon.

Cheers

Yup, gotta love that incredibly simple little "macro" feature!

Well, back to work on the fan controller support now.. got one yet?

-ml

Well, back to work on the fan controller support now.. got one yet?

Nope, haven't done an internal fan.

Ahh.. well, I'm hacking in support for the Empeg fan kit on this page: http://www.benjammin.net/www/pages/projects/

As a bonus, it has a software readable temperature register, which could make up for the broken "stock" one.

Cheers

I suspect that you could use a shell script to do what you want with restarting GPSapp everytime the player starts. I'm not sure if gpsapp traps any signals to 'nicely' stop, or whether the brute force approach below is the only way.

config.ini:

[hijack]
;@DC exec=/path/to/gpsapp.sh


/path/to/gpsapp.sh:

#!/bin/bash
$pid = pidof gpsapp
if [ -n $pid]; then
kill -9 $pid
usleep 10000
fi

if [ -x /path/to/gpsapp ] ; then
/path/to/gpsapp NMEA
fi

exit 0


The usleep is there to give gpsapp a chance to disappear cleanly before we restart it. The value may need to be tweaked - I have no idea. (In fact I have no idea what would happen if the second incarnation of gpsapp happened before the first disappeared anyway.)

Edit: Appended NMEA to gpsapp start line - Not sure if it's necessary anymore.

Well, before I even get that far, I need to figure out why GPSapp isn't working in the car at all now.

When I said before that GPSapp seemed to work, it was when I ran it in home mode without a GPS unit actually connected (still haven't done @DC= as I'm testing it). When I put the player in the car where there actually was a GPS unit, it doesn't work. First try: Blank screen followed by player reboot, second try: blank screen.

Interestingly, it all works in the house, even when I do "force DC/Car power".

Wonder if it has to do with the serial port?

(PS: And besides, the only reason I would want GPSApp to get restarted is because it sometimes locks up because of bugs. The right way to do it is to just fix the bugs. )

Now here's an interesting question...

What if I want to run more than one exec_once or exec?

The INI file format doesn't allow this:

exec_once=program1
exec_once=program2
exec_once=program3

The things to the left of the equals sign have to be different each time. Even if Hijack is smart enough to parse that above, when you edit config.ini in emplode, it doesn't allow double-entries like that (it saves the first one only).

For now, I've got exec_once running GPSapp and exec running empacman, but now I'm full up.

Hmm...maybe. DId you replace the /bin/init with the hacked one after upgrading to alpha14?
AFAIK, the stock init will still try to make the player use the serial port.

Another thing to check - IIRC, gpsapp defaults to NMEA mode anyway, but I could be wrong. It might be an idea to append NMEA to your exec line anyway. I'll update the above script to reflect that.

I wonder if the exec= line would accept multiple arguments;

exec=app1; app2; app3
exec_once=app4; app5

I haven't looked at the source to hijack. I'm sure Mark knows the answer

DId you replace the /bin/init with the hacked one after upgrading to alpha14?

Ah, that must have been it. I'll try to find that hack_init program and use it again.

Pity if that's the case. We're this close to having a system where software upgrades don't kill third-party app installations.

Actually, we're all the way there, it's only GPSapp's need for the serial port that's at issue here. Wish there was a config.ini option to tell the player not to use the serial port, rather than hacking the init.

The exec lines take a single command per line.

To get multiple exec lines, just use an editor that permits it for now.. kinda suprising that Emplode mucks about with it, being none of Emplode's business to do so!

I guess I'll have to hack the syntax in Hijack, maybe do it this way:

;@DC ;@EXEC_ONCE /usr/sbin/gpsapp
;@EXEC_ONCE /usr/sbin/emppacman
...

Whatchathink?

Has anyone explicitly 'wished' for that before?

I wonder if we could persuade the empeg guys to implement that now. I'm guessing that once 2.0final is out we're going to wait a while before the next version is in beta. (Maybe I'm wrong..???)

Okay, I'll make that wish official now (using internal alpha team mail). Because running hack_init fixed it and GPSapp worked in my car just now.

Seems to me kind of odd that they deliberately made the player go to 4800bps in the car specifically so that it could talk to GPS units, but then prevent a third party GPS application from talking on the serial port.

would it be cleaner to do something like:

[hijack]
exec1=app1
exec2=app2
exec_once1=app3

and hijack just ignored the numbers? seems like that might look cleaner than the ;@EXEC_ONCE.

if there's a parsing issue there, maybe a second choice might be:

[hijack]
n_exec=2
exec1=app1
exec2=app2
n_exec_once=1
exec_once1=app3

but it's questionable whether the extra lines are neccessary.

I thought of that idea originally, but decided against it for two reasons:

(1) it'll confuse the heck out of people, and I'll get flooded with emails;

(2) Since the "exec" lines can contain ANYTHING, we really want to ensure that Emplode doesn't get p'offed by anything else that happens to be on such a line, so it is probably best to just have emplode ignore the whole line (by commenting it out).

Ugh, but that's life here

mirror updated to v309

Thanks Mark... it is great to see the kernel exec thing working properly...

I am sorry I had to leave the version I was working on for so long...

Did you manage to get it working from the ftp daemon as well...? This is where I really got stuck trying to return the output. Would make installing software much easier to script from the PC side...

Hopefully sometime soon I will get a chance to come back and do some coding with my empeg. *sigh*

Cheers again,

Kim

Ah.. I was wondering who to give credit to here -- I'd forgotten whose code I picked up and worked on!

I've left much of the pipe stuff in the source, #ifdef'd out for now, because it has a remaining problem in that we cannot simultaneously wait4() for the child, and wait/grab pipe output for display. Solving this usually means yet another thread to mind the user command.

Later, much later..

Cheers! (and Thanks for doing much of the initial work!)