WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Concept regarding loading and unloading an extension  (Read 1919 times)

Offline CentralWare

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 764
Concept regarding loading and unloading an extension
« on: January 25, 2015, 09:05:20 AM »
I have a plan I need a little help brain-storming with...

TC4 boots as usual and I have a custom extension I'd likely to load with onboot.lst...  the extension loads and all is fine.  As part of this extension is Xvesa/flwm and a few other support ingredients.

What I need to do is interact with the user, and once they click "OK" we drop back to the shell, kill X and any other processes we've created and at this point what I need to do is uninstall/dismount this custom extension entirely as though it never loaded (save for possibly a few logs, etc. of course.)

1) I can simply dismount the extension in /tmp/tcloop/extension, delete the mount point and I'm guessing that should cover the bases, but I was curious if TC already had support for tending to such business already built in.  Specifically, something like tce-unload all comes to mind, but tce-unload ext1 ext2 etc would be just as do-able.

2) The interaction with the user is being launched with /home/tc/X.d/script_name.sh - I was curious, if I killed X, would this also kill the script?  (I have to avoid this, of course, as there are things it needs to do after X is shut down which are not GUI based.)

3) (Slightly off-topic) If a problem exists with this project where shutting down X and unloading the extension isn't a decent way to go, is there a way to spawn a new session (from tc account on tty7) onto, say, tty8 and then programmatically switch over to tty8 as a different, non-root user?  (Preferably without adding extensions/software/session managers/etc.?)

4) (A bit more off-topic) From the start of the boot process (where TC indicates version/kernel) is there a way to implement a graphical splash-screen and if so, please elaborate.  (I know others do, but it wouldn't be worth the load if the overhead was severe.)  I already have vesamenu tending to the boot menu, I was just curious as to what could be used for the boot process?

What I'd like to do is create a simplistic, non-evasive (and low-resource) method for user management, graphical logins and the likes, all the while creating a local "mini-repo" of any given software a user has installed on their account (separate "onboot.lst" files basically) without going the expect route if it can be avoided and without having to reboot.  (ie: "Joe" logs in, does his thing, logs out, all traces of his existence vanish for the most part, we revert back to the tc account's login screen for the next user, each having their own secured /home & local, a shared r/o /opt and a bulk /tce which "everyone's" toybox.)

Any thoughts, ideas, concerns, flames, etc. welcome and appreciated!

~TJ~

Offline Lee

  • Hero Member
  • *****
  • Posts: 645
    • My Core wiki user page
Re: Concept regarding loading and unloading an extension
« Reply #1 on: January 25, 2015, 01:35:37 PM »
Quote
1) I can simply dismount the extension in /tmp/tcloop/extension, delete the mount point and I'm guessing that should cover the bases, but I was curious if TC already had support for tending to such business already built in.  Specifically, something like tce-unload all comes to mind, but tce-unload ext1 ext2 etc would be just as do-able.

As far as I know there's no support for unloading extensions.  I don't see why a tce-unload function couldn't be written, but I suspect it will either be limited or complex (or both).  I'd have it delete any symlinks that were created by the extension being removed.

If you're not on resource constrained hardware, you might just leave the extensions loaded and hide the relevant icons and menu entries.

Quote
2) The interaction with the user is being launched with /home/tc/X.d/script_name.sh - I was curious, if I killed X, would this also kill the script?  (I have to avoid this, of course, as there are things it needs to do after X is shut down which are not GUI based.)

Perhaps you could kick off something in bootsync that would wait-for-x and then wait-for-no-x before doing the after-X stuff.
32 bit core4.7.7, Xprogs, Xorg-7.6, wbar, jwm  |  - Testing -
PPR, data persistence through filetool.sh          |  32 bit core 8.0 alpha 1
USB Flash drive, one partition, ext2, grub4dos  | Otherwise similar

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: Concept regarding loading and unloading an extension
« Reply #2 on: January 26, 2015, 04:51:17 AM »
If you search the forum, there's been a few tries at an unload script, but it very quickly brings a lot of complications (app A is running and requires lib B, which you're trying to unload, for example) and so runtime offloading is not officially supported.

Killing X would not kill programs started in .X.d as long as the programs do not require X. All X programs die when X dies.

Running multiple X servers at once may or may not work, it's not a common scenario.
The only barriers that can stop you are the ones you create yourself.

Offline CentralWare

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 764
Re: Concept regarding loading and unloading an extension
« Reply #3 on: January 26, 2015, 05:07:43 PM »
@curaga:
Please find tce-unload TCZ extension.
(Tested only under 4.x, but if the /optional and /ondemand methods haven't changed since, it should operate properly under 5.x and above.)

Example: tce-unload -u mc will unload the Midnight Commander extension if it's loaded.  It will parse dependencies and ensure all dependencies are unloaded as well, IF they're not being used by other extensions.

tce-unload -d mc will uninstall the MC extension (and dependencies) as long as any given item isn't being used elsewhere.

 tce-unload without extensions added will display instructions.

* Instead of deleting, which is what is intended, onboot.lst and ondemand.lst are backed up and replaced and the extensions being "deleted" are just renamed with ~filename.tcz.*.  If it tests out successful, replace the rename with a remove.

There may be more "efficient" methods of scripting this, but it does the job well!
Feel free to add it to the core image if it suits the intended purpose!

~TJ~


EDIT: The unload function assumes if there's an active process running it's named [EXT] without the .tcz extension and is killed off.  If additional processes exist, it wouldn't know what those are (ie: if removing firefox, it would not know flash was running, so unless flash releases when firefox is killed, flash might be left sitting in memory.)

It may also be prudent to add a process scanner for [EXT]-something (such as icewm-1.3.7) where we drop everything after the dash and see if processes exist for just "icewm".
« Last Edit: January 26, 2015, 05:13:22 PM by centralware »