|
* Overview
This document describes the filesystem and directory layout of the
Sharp Zaurus 5500, to help everyone understand better what happens when new software is installed, creating user accounts, and so on. It's not
really a HOWTO in the sense that it doesn't explain "how to" do anything
beyond understand the location of files and directories, and how these correspond to the ROM and RAM on the Z, and why.
Robert P. J. Day <rpjday at mindspring.com>
* The memory layout
The memory on the 5500 is divided into
ROM: 16M
RAM: 64M, further divided into:
memory: 32M for processes/buffers/cache
storage: 32M for additional file/directory storage
You can see the current usage of RAM by clicking on "Applications/System
Info".
In addition to the above, their might also have additional memory on
either a CF card or SD card, whose size and usage would also be displayed
by clicking the same icon.
Superficially, all of the above storage/memory corresponds to the
following locations or mount points by default:
/
ROM
/home
RAM
/mnt/cf
CF card
/mnt/card SD card
and in a terminal shell it will correspond with either of:
# mount
# df
While this is a fair approximation of how memory and directories are associated,
it's actually quite a bit more complicated.
* The directory structure
Again, simplistically, think of the two major mounts points as:
/
ROM
/home RAM
Initially, this suggests that all of the system directories like /bin, /usr,
/etc and so on are read-only, but clearly this is impossible since there
would be no way to do basic administration like adding a new user, installing
new software and so on.
In fact, modifying system files is supported by the fact that there
are about a gazillion links from the alleged system directories and files
into corresponding directories and files under /home, which makes them changeable.
For example,
/etc -> /home/etc
/tmp -> /home/tmp
/var -> /home/system/var
which makes everything in /etc, /tmp and /var read-write. So far, so
good.
In addition, command and software management is also supported by
carefully chosen symbolic links. Consider, as an example, just the
/usr/bin directory:
/usr/bin -> /home/root/usr/bin
This implies that new software being installed under /usr/bin is actually
going into the writable RAM, which is a good thing. But it gets more
interesting.
If the contents of /home/root/usr/bin are examined, most of the contents
are symbolic links back to files in /usr/bin.rom. This means that both
the standard, built-in ROM commands appear to be in /home/root/usr/bin, even
though they're really back in the read-only directory /usr/bin.rom.
And any new software will go in /home/root/usr/bin. The same situation
holds for the other directories /usr/sbin, /usr/lib, /usr/local, /usr/share
and /usr/etc, which means there is access the pre-loaded ROM files
while still being able to add new files.
This same technique is used for additional installation directories:
/opt/QtPalmtop -> /home/QtPalmtop
/opt/Qtopia -> /home/QtPalmtop
Given the above, it's easy to see that the main software install directories
are going to be:
/usr/bin
/usr/local/bin
/opt/{QtPalmtop,Qtopia}
all of which, due to symbolic links, actually reside under /home somewhere.
* The initial system directories
One final point. The initial contents of a number of the critical
directories can be found as hidden tar files in the ROM-based /root directory:
# cd /root
# ls -a
.dev_default.tar
.home_default.tar
.var_default.tar
These tarballs are the initial contents of /dev, /home, and /var (which is really a symlink to /home/system/var). Doing a hard reset reloads all of /dev, /home and /var from these tar files.
When building a custom ROM the initial contents of any of these directories can be changed, by (as root on your Linux box) untar the appropriate tarball, make the changes, then tar it back up. You have to do it as root so that root is the owner of the files in the tarball. (fakeroot should work here, if you're familiar with that.)
|
|