Create new software modules

Once you have an SDK and some space available on your harddisk you can start creating your own software modules to add applications to dyne:bolic, see the "Extra software modules" section of this manual for more information about features and usage of .dyne modules, now we'll go on with some instructions on how to create them.

First of all make sure you dock your system on a harddisk, then create an SDK (see previous chapter). When you have an SDK directory in your harddisk you can see it's location just typing:

[d:b] ~ # echo $DYNE_SYS_MNT/SDK [Enter]

Next step is to create the module directory in the SDK, so let's choose our module name first: we are going to create the spaghetti module, with the commands

[d:b] ~ # mkdir -p $DYNE_SYS_MNT/SDK/modules/spaghetti [Enter]
[d:b] ~ # mkdir $DYNE_SYS_MNT/SDK/modules/spaghetti/bin [Enter]
[d:b] ~ # mkdir $DYNE_SYS_MNT/SDK/modules/spaghetti/lib [Enter]
[d:b] ~ # touch $DYNE_SYS_MNT/SDK/modules/spaghetti/VERSION [Enter]

basically we are just creating the bin and lib directories and a VERSION file inside the module, you can do that with any filebrowser or midnight commander if you like: c'mon, make yourself comfortable ;)

The last thing to do is to activate our spaghetti module, mounting it on /opt/spaghetti since all modules are activated in the /opt prefix. To do that we use again a DyneSdk command

[d:b] ~ # dynesdk mount [Enter]
[d:b] ~ # source /boot/dynenv.modules [Enter]

That's it! our new module is mounted in /opt and we have our PATHs configured accordingly.

Keep in mind that you need to use dynesdk mount once after every boot, before starting development on your module. You can as well open up for development an already existing module (your good old gnocchi module for instance) with the command:

[d:b] ~ # dynesdk devel gnocchi [Enter]

You'll be then prompted with a question, if you want to decompress the content of the module for development, with an indication about the space that will be occupied by it on your harddisk.

Now you can compile the spaghetti software you like with

[d:b] ~ # ./configure --prefix=/opt/spaghetti [Enter]

or editing the PREFIX in the Makefile in some cases - and don't forget the sauce! :)

To make it easier, when software is built with the usual "./configure && make && make install", you can use the dynemodconf command (followed by the module name) instead of calling ./configure directly: that will set the prefix and more environment correctly, for example to compile "aglio-0.5" with flag "--with-basilico" inside our spaghetti module:

[d:b] ~/aglio-0.5 # dynemodconf spaghetti --with-basilico [Enter]

Once you are done with cook... ahem, compiling, then you can squash everything into a compressed .dyne module with

[d:b] ~/aglio-0.5 # dynesdk squash spaghetti [Enter]

and that's it! your new module will be found in $DYNE_SYS_MNT/dyne/SDK/cdrom/dyne/modules/spaghetti.dyne and ready to be included in the next CD ISO that you can pack with dynesdk mkiso.

Before releasing your module into the public, is a good idea to fill up some information about your creation so that people can contact you and visit software homepages. That's what the VERSION file is for, and it's format is very simple:

name            Spaghetti
desc            spaghetti pizza mandolino e presidente scemo
version         1.0
url             http://tuttifrutti.org/spaghetti
packager        The Crazy Cook http://tuttifrutti.org/~crazycook

Just use your favorite text editor to fill in these fields, leave a space or a tab between the field name and value and that's it.

You can add entries and submenus for the user to start up your software. To do so create an applist file inside your module's etc directory, like for example /opt/spaghetti/etc/applist. The applist file will list application binaries, descriptions and ways to start them up thru flags. Here it follows a description of the format, basically a | separated list:

# format:
# name | description | command | flags | web url | author

# flags:
# runonce | multi = if there should be only one instance running, or not
# terminal        = if it should run in a terminal
# manual          = if it's a manual entry
# root | user     = if it must be run as root or as user

# submenus can start and end with
# Begin | MySubmenu
# End | MySubmenu

for example:

Begin | SPAGHETTI

AglioeOlio | aglio olio e peperoncino | pasta --agliolio | | http://tuttifrutti.org | The Crazy Cook
Puttanesca | olive capperi e alici | pasta --puttan | | http://tuttifrutti.org | The Crazy Cook
Pesto | pesto alla genovese | pasta --pesto | | http://tuttifrutti.org | The Crazy Cook

End | SPAGHETTI

You can also have submenus, just use Begin and End once again inside. For a complete example see the system application list in $DYNE_SYS_MNT/applist.

In case your module needs to set environment variables (like custom paths and general settings for applications) you can simply declare them in a env file inside the etc directory. That file can contain declarations of environment variables, one per line, which will be exported in the running system, for example in our spaghetti module /opt/spaghetti/etc/env will look like:

KITCHEN_PATH=/opt/spaghetti/lib/kitchen
GLOBAL_TASTE=spicy
COOK_PROFILE=big_nose

You can include your own home settings inside a module, so that they will override the default dyne:II user settings. This is useful when you want to change the window manager default configuration (with a new desktop image for example) or deliver pre-configured applications (with a .config file in home). To do this you simply have to create a skel directory inside your module: all files that are included in it will be automatically copied into all users home directories and setted up to be adopted for users that are created in future. <

In your modules you can include any kernel module correctly compiled for the dyne:II kernel. To do this you have to create a kernel directory inside your module: all kernel modules contained will be searched and loaded if found by the loadmod command, to be used instead of the standard modprobe. In case the module is not naturally requested by your hardware configuration (not listed by the pcimodules command), you build your own detection or force loading of your module inside a module startup script. You can prepare a script inside your module to be executed every time your module is activated. To do this you have to create an etc directory inside your module: all executable files included in the rc.* wildcard will be launched at startup, with the first $1 argument being the name of the module itself.

So here is resumed the file structure contained in modules:

VERSION required file 	    contains information about the module and its sources
bin 	optional directory  contains all binaries, automatically included in $PATH
lib 	optional directory  contains all libraries, automatically included in $LD_LIBRARY_PATH
etc 	optional directory, contains rc.* startup scripts executed at activation
skel 	optional directory, contains all settings to be added to /home/user and /etc/skel
kernel 	optional directory, contains kernel modules that can be loaded by loadmod

You have the power to create, now go make something wonderful! :)