It would have to remount / as writable and such. I would really advise against doing anything like that in such an ad-hoc fashion ...

fsck'ing / isn't a huge deal, and we're not really modifying any data other than dirents, so I wasn't too concerned about that.

and you can't also sit through a script that'll take about 2 seconds?

It's not the time, it's just the additional steps I have to remember. Each time I upgrade the player, I already have a bunch of stuff to do and I keep slipping farther and farther away from being able to remember all of it each time.

If we had that Hijack feature I talked about, I could put everything in drive0/var somewhere and would never have to do ANYTHING on a re-upgrade.

Hey Tony, we're talking the JEmplode wishlist thread about simplifying 3rd party app installs to a point and click thing which should at least ease this concern.

But what you are asking for here is a technical challenge - unix and linux systems usually only pass control to userland once - via init. init is then responsible for spawning whatever is needed in userland, and the userland/kernel interactions at that point are fairly limited to system calls from userland.

The problem here is that the empeg-supplied init is locked down to only do one thing - start the player. And always tells the player to hog the serial port. Even if hijack were able to start arbitrary userland applications, gpsapp would still need to start before the player in order to work (and then the player wouldn't) . Now this again could be solved in hijack - we could (optionally) remap the serial device (/dev/ttyS0) to a dummy device that does nothing but dump the data, and then tell gpsapp to use /dev/ttyS1 that would really point to the port. This potentially would allow hijack to remap the port at will from a menu item - allowing either gpsapp or player serial messages to be using the real port at will. If my serial port expansion plans come to any fruitition then it would use a scheme similar to this - but I digress.

What would pretty much solve the init issue is if the empeg guys included preinit in the distribution. Only hijack kernels would use it - so it would be transparent to non-HJ users. And whether the player uses the serial port should be a config.ini setting.

Once that is done it is comparatively easy to get JEmplode (or some other software) to deal with the rest of 3rd party app installs.

What would pretty much solve the init issue is if the empeg guys included preinit in the distribution.

But wouldn't they be loath to do that, because if preinit could execute arbitrary code from one of the drives that doesn't get wiped on a .upgrade, then you could theoretically render your player unbootable in a way that .upgrade wouldn't fix? A builder image would, but a regular .upgrade wouldn't.

Empeg guys, any of you listening here? Got any ideas?

if preinit could execute arbitrary code from one of the drives that doesn't get wiped on a .upgrade, then you could theoretically render your player unbootable in a way that .upgrade wouldn't fix?

No, because preinit will only be called by hijack kernels. It exists as the file /sbin/hijack, which hijack will try to execute in favor of /sbin/init. The default kernels won't do that. Hijack will fall back to /sbin/init if /sbin/hijack doesn't exist. Both kernels will then fall back to /sbin/sh if init doesn't exist; that's a standard feature of all(?) Unix kernels.

Interesting.

Hmm. Empeg guys... Listening?

It exists as the file /sbin/hijack, which hijack will try to execute in favor of /sbin/init.

Wait wait wait.

What if hijack were changed so that preinit could exist somewhere specific on Drive0 instead? Then one wouldn't have to re-install preinit on each upgrade, and the empeg guys wouldn't have to get involved.

Then if your mountpoint stuff could somehow be worked into a startup script, preinit could be a painless thing. Then all add-ons could go onto Drive0 and nothing would never have to be reinstalled after a .upgrade.

It's not the time, it's just the additional steps I have to remember. Each time I upgrade the player, I already have a bunch of stuff to do and I keep slipping farther and farther away from being able to remember all of it each time.

Why not just add the details to the FAQ and then refer yourself to it when you need to do an upgrade...



(I tried so hard to resist it)

/drive0 isn't mounted during boot, so you cannot have preinit on /drive0 and start it before /sbin/init mounts the drive.

Why not just add the details to the FAQ and then refer yourself to it when you need to do an upgrade...

Oof!

Only the root parition (flash) is mounted at that point, and the player app mounts /drive0. /programs0 is mounted through a preinit script.

the player app mounts /drive0

Yuck. How much time would it add to the boot process to have the kernel mount /drive0?

Theoretically speaking, not much. But, It's Not The Correct Thing To Do(tm). I don't know whether that might affect the player in any way (the players mount command would 'fail')

Is it me, or are we holding the same conversation in 3 different threads now?

How much time would it add to the boot process to have the kernel mount /drive0?

Have the kernel start mounting other filesystems before it passes control to init.

EVIL!