On Tuesday 04 February 2003 22:45, David Heremans wrote:
> /usr/share/openMSX/ : Base dir for shared data
> +-- /bin/openmsx : binary itself
> +-- /cfg/settings.xml : global settings file
> +-- /cfg/Console*.png : needed files for the console
I think of the console images as a first step towards a skinnable UI.
Therefore I would prefer that they are assigned their own directory, instead
of sharing one with settings.xml.
> +-- /defaultmachine : redirects to a concrete machine
> config file
Symlinks are not available on Windows. If we can find a more portable
alternative, I am in favor of that. Maybe we can store the default machine in
> +-- /machines/
> +-- /Philips_NMS_8250/ : directory per machine
> +-- /msxconfig.xml : configuration of the machine
Is this file called "msxconfig.xml" in every machine directory? I think that
would be a good idea. What about peripherals, same file name or not?
> +-- /roms/ : roms for this machine
> +-- /disks/ : default disks for this machine
> +-- /saves/ : sram data for rtc
System-wide directories should not be writable, so a saves directory would be
useless. Even when running as root (usually a bad idea), saves should be
written in root's homedir, not in a system-wide directory.
> +-- /peripherials/
Typo: should be "peripherals".
> +-- /fmpac/
> +-- /saves/ : sram data from the pac
> +-- /MusicModule/
I'd like a convention for directory names: either "FMPAC" and "MusicModule" or
"fmpac" and "musicmodule". My personal convention is to use all lower case
for directories that are mainly used by automated processes and mixed case
for directories that are mainly used by users, for example directories
containing documents, audio, video etc.
Should we follow that guideline, we have to ask ourselves whether these
directory names will be presented to users or not. So if a user is presented
a list of peripherals in a GUI, are the peripheral names taken from the
directory names or from elsewhere?
I prefer to put the user-readable peripheral names in XML. This has several
- No problems with special characters, such as spaces, colons, non-ASCII
- Translation of names is possible without changing the directory structure, a
single XML file could contains all known translations and select one based on
the user's locale settings.
- Other meta info could be added, such as a description in a few sentences,
name of the company/group/person that created the peripheral, a photo etc.
So I think all lower case directory names would be best.
Note: I think it would be useful at some point to merge the hardware
configuration format openMSX uses and the hardware database Alex and Manuel
are building. There is a lot of info in there that is interesting both on a
web site and when running an emulator. The technical details such as amount
of memory, slot map etc are necessary for running the emulator and this is an
easy way to verify their correctness and completeness. The background info
such as manufacturer, photo etc are what readers like to see on a web site,
but also make a nice addition to an emulator GUI: clicking on a photo of an
FMPAC is more appealing than selecting "fmpac.xml" in a file dialog.
> +-- /software/
> +-- /roms/
> +-- /disks/
> +-- /tapes/
Should these be part of the openMSX package? I think most users already have
directories containing MSX software. I'm not storing my MP3s in ~/.xmms, so
why would I store my DSKs and ROMs in the openMSX directory?
> This structure is repeated in ~/.openMSX and ~/openMSX
> For the documentation I propose /usr/share/openMSX/docs/ and a link in
> /usr/share/doc/openMSX towards this directory and ofcourse the needed
> default links in /usr/share/man and /usr/local/bin/
I think it would be a good idea to use DocBook for openMSX user documentation.
Then it is possible to generate man pages, HTML documentation and PDF
documentation from the same source document.
> Rationalisation for the structure
> 1) the base dir for the global data directory will most likely be different
> for different OS, and even in between distributions of a same OS :-). So
> this must be configurable, at least at compile time. There is no rule of
> thumb for this just observed 'common behaviour'. If we pretend to be Big,
> we should go for /opt/openMSX since most commercial big packages use this
> selfcontaind directory structures (think Oracle, IBM WebSphere etc) For the
> moment the /usr/share/openMSX is selfcontaing as well, although most
> packages I looked at seem to split of the docs to /usr/share/doc/ and
I like having packages such as openMSX in a self-contained directory. It makes
life a lot easier when compiling them from source, because you don't have to
rely on a package manager to keep track of which files belong to which
package. Also, it is possible to install multiple versions of the same
package at the same time.
However, I prefer /opt over /usr/share. The Filesystem Hierarchy Standard
(http://www.pathname.com/fhs/) describes /usr/share as follows:
> The /usr/share hierarchy is for all read-only architecture independent data
So the openMSX binary does not belong in /usr/share. Saves do not belong there
either (/var is the proper location for writable system-wide files), but as I
argued earlier, they do not belong in system-wide directories anyway.
Also, it seems /usr/share usually contains data for applications, but not
self-contained application directories, unlike /opt.
By the way, the FHS does not specify any size requirements for packages in
> 2) for all users and global data the files in /usr/share/openMSX/ are used.
> For personal settings the directory openMSX and .openMSX are used. We have
> both a hidden and a visible openMSX directory. Most users will probably
> want to have theire machines xml's savestates etc in the hidden one. And
> all the games/software in the easy-to-access directory (theire GUI programs
> can be used to look at which games they have, since most of those will by
> default hide the dot-directory)
I think it's confusing to have both ~/.openMSX and ~/openMSX. I prefer to only
use ~/openMSX, but if the majority prefers ~/.openMSX that is fine with me,
as long as there is a single directory.
> 3) Save states can be stored in the global directory to have an initial
> savestate file. Writting save states should be first tried in the
> ~/.openMSX, then in the ~/openMSX directories and finaly in the
> /usr/share/openMSX. The behaviour should be like alternating between the
> 3 base directories.
As said before, saves should only be written to a user's home directory, not
to a system-wide directory and there should be a single openMSX directory in
that home directory. So that leaves a single location for saves, which
> 4) The default machine is read from the msxconfig.xml in the defaultmachine
> directory. On a unix this could be a link towards the wanted machine
> directory. On a system that doesn't support links-like-we-know-it an
> enduser can simply copy the machine directory and rename it to
Copying is not a good idea, since the copied directory is not automatically
updated when the original directory is.
As I suggested earlier, we could store the default machine name in
settings.xml. This is a kind of link, just as HREF in HTML. As a bonus, it
avoids defining a search order for defaultmachine, since the search order of
settings.xml is used.
> 5) When launching openMSX the search order should be ~/openMSX (most
> visible), ~/.openMSX (not so visible but still personal) and finaly
> /usr/share/openMSX. When saving files (sram) the order mentioned
> above (point 3) should aply.
What about a system-wide settings file in /etc? I was eventually convinced it
is a good idea to have one, but now it is no longer in the proposal. The FHS
says packages in /opt should have their system-wide settings in /etc/opt, so
let's use /etc/opt/openMSX/settings.xml.
At some point in the future, it might be a good idea to have a system-wide
hardware description directory outside of the openMSX package directory, so
that the hardware descriptions and openMSX itself can be upgraded
independently. But it is too early in development for that now, so don't
include this in the proposal yet, just keep it in mind.
What is the granularity of the search order? Is it applied on a per-file basis
or on a per-directory basis? For example, if I have a full system-wide
NMS8250 machine directory and I put a modified msxconfig.xml in my home
NMS8250 machine directory which does not contain any other files, should
openMSX use the system-wide ROM images, or should it complain about missing
My preference is directory granularity for the search order. Although slightly
less powerful, it is a lot clearer, because every directory is
self-contained. For example, you can be certain that a machine directory that
you have tested in your home dir does not have any hidden dependencies to
system-wide files, which will cause it to malfunction on other people's PCs.
Directory granularity also reduces the amount of searches, but I don't think
this is critical for performance.
Note that because the search order for writing is different from the order for
reading, the write directory must be resolved independently from the read
directory. So save states go to the user's home directory, even if the config
was read from a system-wide directory. But all save states for a machine are
written to same directory and later when they are restored, they are all read
from the same directory.
> Note that the filehandler code must be adapted to cycle trough the 3
> basedirs. Also note that the relative-to-config-file code must also do this
> implicitely, especially in the case of the RTC file. openMSX could have
> launched using the files in /usr/local/openMSX but when it closes it should
> first try to save the RTC in ~/openMSX. If the file can not be opened for
> writing or the directory doesn't exists we fall back to ~/.openMSX and
> finally to /usr/...
I think that if the openMSX user dir (~/(.)openMSX) cannot be opened for
writing, it should be created automatically. If that fails, throw an
exception. A higher layer can catch that exception and present an error
message to the user.
> I was thinking about
> 1. runnning openMSX so that it uses /usr..defaultmachine
> 2. quit so that CRT gets saved in ~/.openMSX/defaultmachine
> 3. replace the link in /usr/... to other machine
> 4. run openMSX again so that it uses /usr..defaultmachine
> This time the CRT from ~/.openMSX/defaultmachine
> is used with an other MSX machine.
This is another reason not to copy machine configs to defaultmachine, but use
a linking mechanism of some sort instead.
By the way, do you mean "RTC" (clock chip state) here? If not, please explain
what CRT files are.
> 2) If they link the defaultmachine-dir in ~/.openMSX directly
> to a /usr/... the CRT file that we save will end up on
This problem is avoided when using just the machine name as a link, instead of
its full directory path.
> Maybe it is good that for the saves we can automatically recreate the
> apropriate dir-structure in ~/.openMSX so that if we run a new machine from
> /usr/.../machines/.. that the CRT saved is held personal and uniquely in
> the users ~/.openMSX. This way only the saves are stored per user but the
> roms will still get found in /usr/...
> If we find a way to get the "exact" machine name from the config.xml then
> the problem with the defalt machine can be circumvented as well since
> then we do not write to ~/.openMSX/defaultmachine/saves but we replace
> 'defaultmachine' with the correct'machines/brand_model_name/' and thus
> save to fi. ~/.openMSX/machines/Philips_NMS_8250/saves.
This is another argument to store the default machine name in settings.xml:
instead of getting the machine name *from* the config, the machine name is
used to get *to* the config.
> Ok, let the counter arguments come...
You have just read them. I do like the general approach though, it just needs
some fine tuning.