Well, first ..
You can of course do anything you want; your box, open source evreything, make it do what you like
But let me discuss a bit from a normal user perspective (ie: not hacking in knee deep.)
The normal unix filesystem will be on NAND. ie: /usr, /etc, all that. You can reflash that to put a new firmware in and several groups are even working on alternative firmware (ie: gentoo etc.) Anyway, consider -- if you run a normal unix packager, it doesn't know about SD versus the normal filesystem. It would be unadvisable to put user homedir on SD by default, since you might not have SD in, or might swap SDs, or any number of scenarios.. so user homedir must also be in NAND by definition. This means if you use a normal unix packager like apt or whatever, its going to install things in /usr/local/bin say, and your homedir ~ etc, all on NAND, which is fine, it'll work.
But what if you keep installing packages that way..
1) They're on your NAND; which is cool, no worry about losing them. But..
2) You have limited NAND space; you might want to reserve it for user documents that you find important or whatever.. but do you want ot fill it up with new builds of firefox etc? I mean, if you want 500 packages, your NAND will not have the space for it.
3) The firmware lives on NAND; if you fill it up, it might be hard for the pandora team to guarantee theres enough space for next firmware update (ie: not a reflash, but a patch, say.) So it'd be nice to not have everyone by defaut using a packager that fills up the limited resource
4) .. and so on.
The trick is unix packagers assume the filesystem is where they want to put stuff. It is less likely to be the case on a handheld.
(You could format an ext2fs on SD and mount that and so lots of tricks, but we want to make it simple. For the knowbies, they can do all that of course.)
So a bunch of keener fellows have been banging out what we think is a better idea.
THIS IS ALL UP IN THE AIR AND IN DEVELOPMENT, SUBJECT TO CHANGE ETC AND SO ON.
The nitty gritty ideas we had were to divide NAND up into a couple regions; a firmware chunk and a user homedir chunk. The trick is we could use unionfs (or aufs, a newer union-fs style system). We'd make te union setup so that writes to the firmware filesystem are actually written to the user section in your homedir somewhere, an the unionfs proprerties make it so the system doesn't see this. ie: You write to /usr/foo and it ends up in your homedir in NAND, but reading /usr/foo works still. This way if you overwrite stuff in the firmware and blow it up, you just wipe your homedir and reboot, and bam, you're back to a fully working stock firmware. For OS patches we can mount the real NAND fs instead of the union, update the filesystem, remount he union, and poof. Seems brilliant to me, and allows normal packagers to just work, reasonably risk free.
Thats the firmware side.
The app packaging system we're designing uses some similar tricks, in theory. (We're still bangin it out, but its looking cool so far.)
We define a new package type, .pnd. An app could be whatever.pnd, and it includes the PXML file as defined by ED. (Though we've modified the contents of the PXML a fair amount since his last update.) The pnd could be a number of file formats (think of it like a zip file with a PXML appended to it, but we're likely going with an .iso format. Make an iso of the directory you want, append the PXML, rename to .pnd .. good to go.)
Insert your SD into the pandora, a daemon wakes up and detects the .pnd files in its searchpath, and it generates the .desktop files for the launcher in a configured location. (It could also be made as a module for matchbox or other window managers, but our current thoughts are to spit out .desktop files since they're pretty standard and should work simply.) you pop out the SD, the daemon wakes up and rescans, and removes the .desktop files in question. (It should also handle if you just rm the pnd file from within the pandora usage, etc.)
In essence, you go to the gp32x archive (say, or others), download a few .pnd files, drop them on your SD, and thats it. Just works.
More nitty gritty -- the idea is that when the system finds these pnd files, it uses filesystem tricks again.. using fuse filesystem it the pnd files are mounted as .iso's into the filesystem, based on their unique-id in the PXML say. ie: mount whatever.pnd into /apps/123456uniqueid123 and the PXML file part identifies which file in there is the executable and icon, etc. The launcher shows the icons based on the.desktop files, and when you tap one, the launcher knows which executable to run, right out of /apps/123etc/.
What makes this extra clever is unionfs again (ao aufs etc), so that any writes back to /apps/123etc/ go to the SD card instead (but the app doesn't have to know.) ie: Say, to SD card /pandora/appdata/123etc/ dir.
Anyway, the trick is you download a .pnd file, it gets shown in the launcher based on its PXML config. you tap to run it, and it gets mounted, run, and unmounted on exit. Everything works right off your SD including new/changed data. Your .pnd file remains clean (you can copy it to someone else, etc, or delete it) and your apps data stays on your SD card.
You can also unpack the .pnd files yourself into their directory and just drop it on the SD card. In that case, no mount voodoo is needed, so writes back to /pandora/apps/whatever just stay there, for those who want to keep it all together like a traditional gp2x app.
As to locations..
I've overkilled the design really.. everything is based on searchpaths. So pandora apps will use libpnd as their infrastrucuture (to save everyone rewriting all this every time.) A simple call will check the OS and find out the config search path (which can be altered in NAND as you see fit.) Then any time an app needs a config, the config search path is seeked to find it.. so you can use the default config in NAND as shipped, or put replacements of those config files on SD. (Pull out your SD and everythign reverts to defalut firmware config.. seems nice and safe to me!)
The search-path for where apps can be sought after is configured; by default the pnd files and unpacked pnds will be looked for in SD (both) in /pandora/apps if I recall right, including any subdirectories there so you can organize as you see fit, and also a path or two in NAND for built in pnds. (built in apps will probably be built into the normal filesystem like any unix app, but we could possibly include some apps as pnd files so that the user can remove them if they don't want them, to get NAND space back.)
Now, if you want pnd files to be droppable right in SD root, you just add a /pandora/conf/apps config file and put the search path into it, or edit the master conf file in NAND (/etc/pandora/conf/apps is my current plan for that.) Thus you can put .pnd files anywhere you want, but we'll have a defalut behaviour as shipp.ed
Now, before anyone complains, every single path and decision there is in conf files, so you can specify where you want to do things.
And you can use normal unix packagers.
And you can alter things to work as you see fit.
So I think we're keeping the usual flexibility, but also making something dumb-simple for new users, and yet you can play with it to customize it for those woh want to roll up your sleeves. There should be little risk since you can just eject SD cards and/or wipe oyur NAND homedir to revert to built in functionality. And in a pinch, if you wipe everythign out, you can reflash the whole firmware.
Safe and awesome.
Hope it sounds good!
Bunch of hackers in their spare time, woowoo
jeff
Included with the firmware will be a good assortment of libs.. SDL etc. So dynamic linking against that stuff will likely be the way to go, which is nice. (Or stat link to your hearts content if you need/want to.)
pnd files aren't going to magicly handle dependancies AFAIK; they're more for apps, like Mac OSX app bundles. a .pnd file includes everything it needs to run the app, that is not part of the firmware. A self contained package, just like a MAME gp2x zip file, say.
jeff
