FreeBSD and lagg at boot

I was experimenting with my FreeBSD and lagg(4), the link aggregator.

The idea is to perform a network interface teaming using more than one at the same time with a specific protocol, for instance, to provide high availability and redundancy.

So I fired up my VirtualBox instance with the more NICs I could and did some aggregation. Nothing special so far.

When I was satisfied, I tried to put the same configuration in /etc/rc.conf to enable it on boot, but here comes the problem: I was unable to create the lagg interface and, consequently, to aggregate NICs.

It tooks me a while, but finally got the hint from the rc.conf(5) man page: cloned_devices! This variable contains a list of interfaces that are clonable, and therefore created on boot.

Since it was not so simple to find out how to setup the rc.conf, the following is mine in the hope it can help anyone.

############################
## Link Aggregation Setup ##
############################
#
# First of all bring up the interface,
# then create the lagg0 interface using the
# cloned_interfaces (which in rc.conf means
# to create the interface) and then
# with a single command bring up the lagg0, specify the
# protocol to use and add each interface (laggport).
#
#
ifconfig_em1="up"
ifconfig_em2="up"
ifconfig_em3="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="up laggproto roundrobin laggport em1 laggport em2 laggport em3 192.168.200.222 netmask 255.255.255.0"

FreeBSD VIMAGE

I never noted VIMAGE, the kernel virtualization project of FreeBSD  until I read that PCBSD was making changes in order to use VIMAGE on jails.

The idea behing VIMAGE, also called VNET, is to provide a self-contained-per-jail-status in order to virtualize modules and their behavior. This translates to the opportunity to virtualize network stacks on a per-jail basis, something that reminds me the OpenSolaris CrossBow Project.

PostgreSQL & DTrace @ FreeBSD

Tempo fa mi ero scontrato, o meglio scornato, con la compilazione di DTrace e PostgreSQL (o meglio, la compilazione di PostgreSQL con DTrace) su FreeBSD. L'ultima volta, dopo aver riportato i problemi nella lista pg-hackers, avevo anche aperto un bug sul tracker di FreeBSD.

Ad oggi il problema non sembra ancora essere risolto, forse che non sia così interessante usare DTrace + PostgreSQL + FreeBSD?

Pare comunque esserci una soluzione da provare, legata al caricamento dinamico dei moduli di DTrace nel sistema prima di iniziare la compilazione.

FreeBSD and Whatsapp

La FreeBSD Foundation ha ricevuto una grande donazione dal CEO di Whatsapp. Fa molto piacere vedere che le aziende stiano riconoscendo, sempre piu', il valore ai grandi progetti Open Source che hanno permesso il loro business.
E il mio personale invito è anche quello di valutare altri progetti, forse piu' detro le quinte, ma che movimentano molti piu' dati come OpenBSD (mai fatto un login ssh?).

If Linux did not existed...

Paul Venezia published an interesting article  where he

analyzes what the history of FLOSS could have been without Linux.

Whilte it is worth reading this article, I have to say that it seems to me the conclusions are quite trivial. In particular, assuming Linux never existed, the article states that all the hackers and developers in the world would have been part of the BSD movement. From this, the natural and easy conclusion is that the BSD operating system family would have been much more advanced than what is today.

Well, I don't agree with the article, and it seems to me this is a quite shallow conclusion. One key point of the Open Source movement is the ability to "fork", that is to create another project on the shoulder of an existing one. Having said that, and considering that, as the author states, Linux developers have reinvented the wheel in the beginning, what would have prevented such developers to fork or even start over and get a new project from scratch?

License is another issue that, in my opinion, invalidates the article conclusions: Linux has been released as a GNU project, while the BSD operating system family is, well of course, BSD license. License is religious aspects to many developers, and therefore I assume that many of them would have never chosen a BSD project, again pushing a fork/scratch with another license.

What about the different BSD distros? I believe all of them would have been existed anyway. After all NetBSD was founded when 386BSD was already running, and OpenBSD was founded from NetBSD controversy, and therefore none of these includes a specific Linux-related issue. Other BSD distros, like PCBSD or FreeNAS and the others would have been the same history as of today.

In the industry marketplace I believe some differences would have been generated: today the market is split between the Linux embedded systems and the (Free)BSD ones. As an example, Apple has based OSX on FreeBSD userland and BSD kernel, while Sony and others are basing their multimedia products on Linux. Since Linux has gained a very strong momentum, the hardware support is better than in other BSD systems, and I'm referring to consumer and commodity hardware, not server and high end devices. Therefore, the choice today is about hardware support, and this leads many vendors to choose Linux instead of a BSD system, even if this could break the license (think about the TiVo). If Linux had never ever existed I believe that hardware support for BSD based system would have been better because vendors would not have been any choice of supporting this kind of platform.

A final note is about numbers: many Linux distributions have a lot of people devoted to quality control, source code management, community and advocacy management, and, of course, development and packaging. BSDs have a lot less people available and this is, in my opinion, a big difference: BSDs systems can assure the today's high quality thanks to ability to keep their staff under control. If Linux never existed and a lot of more developers and members would have joined BSDs projects, would have been the quality be the same of today's? I don't think so, and therefore my final conclusion is that if Linux never existed something in the world would have been happened to create a very similar ecosystem.

Microkernel(s)

Quite often I find on the web threads related to the "microkernel" cutlure versus the "monolithic" kernel one.

First of all, I have to say I'm not an expert in the former, but I would like to provide some insights from what my experience has been so far about the two approaches.

Please consider we are not really and strictly talking about Operating Systems kernels here: the approach can be extended to pretty much every complex software system.

So what is a microkernel architecture? Essentially it is a complex system made up by small pieces that cooperates and coordinates each other; each component is pluggable and can be substituted without a whole system reboot or downtime. The key point here is that EVERY component can be replaced/upgraded at run-time without having to stop the system as a whole.

In order to achieve this run-time behavior, the system must provide a strong decoupling of modules via a kind of message-passing scheme, and therefore we could state that the messaging delivery system is the only one that is going to require a whole reboot when changed.

The most famous Operting System based on microkernel is Minix, but this is only a huge example of this kind of architecture. OSGi is another example of a dynamic system where pretty much everything can be plugged at run-time. STREAMS, the old SunOS networking layer was also based on such concept. Erlang reminds me a microkernel architecture.

Are microkernel systems good or bad? It depends. When the task has to be low level, microkernels are generally bad. As an evidence of this, even if Minix is still under active development, all the rest of the world has chosen another approach, and I believe that if great OSs like FreeBSD, OpenBSD, Linux have chosen and still continue to resist to microkernel, they cannot be totally wrong.

STREAMS have been kicked off as soon as the network load increased, due to the performance lack.

On the other hands, OSGi is very succesfull, being the system not a low level one. The same role/agents systems I developed during my research activity could have been thought of a microkernel kind of systems, and while they were very dynamic, performances were not so good as a statically bound system.

So what?

If dynamism and pluggable features are the most important parts of your project, go for a microkernel approach. If performance is your aim, avoid a microkernel.

This is my personal opinion.

Room Number 621: EuroBSDCon!

I attended the Euro BSD 2013 in Malta, on the last week of September.

The conference was a great mix of technical and social knowledge and represents a great opportunity to meet, talk and learn directly from the /Unix-gods/ of any time and nation. For instance, I was sitting near the legendary McKusick while listening the great Theo De Raadt during his keynote about the time_t overflow problem.

I had the great opportunity to see and meet people I've only seen as names on mailing lists, and the technical quality of many of the talks was really good. Several talks were related to the [[http://www.openbsd.org][OpenBSD]] project, and I have to say I'm every day more interested in this project more for its policy than for its technology; but this is another story.

I had nothing but good words to say about the event and the organization, and definetely was worth being there.

I had also the opportunity to visit (again) Malta, which is a very nice place to be and to spend a few days.

Esce pfSense 2.1

E' stato annunciato oggi pfSense 2.1, la nuova major release del sistema di firewalling, routing, vpn basato su FreeBSD: Fra le varie novità di networking si trovano un aumentato supporto per IPV6 e anche il supporto nativo al formato PBI (Push Button Installer) creato per PCBSD.

La release note ufficiale si trova qui.

etags su progetti grandi

Solitamente uso etags unito ad Emacs per sfogliare il codice sorgente di progetti anche di grosse dimensioni. Tuttavia indicizzando la code base di FreeBSD mi sono trovato degli strani errori di riferimento: di fatto Emacs saltava nel punto sbagliato portandomi da un tag all'altro apparentemente senza senso.

Ho poi scoperto, grazie all'aiuto sulla mailing list Emacs, che sbagliavo l'invocazione della generazione dei tag:

cd /usr/src && find . -name '*.[ch]' -print0 | xargs -0 etags

questo comando sfrutta la capacità di xargs di lanciare piu' job in parallelo, e quindi ci si trovava ad avere dei processi etags concorrenti fra loro che sovrascrivevano le modifiche in modo conflittuale.

Siccome etags consente di leggere direttamente da standard input i file da indicizzare, il seguente comando risulta piu' lungo ma accurato nei risultati:

cd /usr/src && find . -name '*.[ch]' | etags -

Sony, AMD & FreeBSD

La nuova console da gioco della Sony, la PlayStation 4, avrà un sistema operativo Unix based denominato Orbis. Non è una novità, e fin dalla prima versione è stato possibile installare Linux sulle console della Sony. 

Ma Orbis, a differenza dei suoi predecessori, è un sistema discendente diretto di FreeBSD. In sostanza quindi Sony passa da Linux a FreeBSD, e la cose è importante sotto due aspetti fondamentali:

• incrementa la visibilità di FreeBSD aggiungendo un altro dispositivo embedded (dopo quelli della mela) ad avere dei sistemi discendenti diretti Unix;
• crea un forte legame di cooperazione fra AMD e Sony per i driver della scheda video (Radeon) e dei multicore (8 nella PS4).

C'è da sperare che le personalizzazioni, soprattutto quelle per i driver della scheda video (parte nella quale FreeBSD è carente rispetto al pinguino) siano presto rilasciate come ports o come driver binari.

Sulle motivazioni che hanno spinto Sony a questa scelta non si sa ancora nulla di certo, ma è facile indovinare come la licenza piu' permissiva di FreeBSD e la maggiore stabilità abbia giocato un ruolo molto importante.

BSDA Certification Exam

One of the reasons that forced me to go to the Central Europe BSD Day 2013 was to take part in the BSDA Certification Exam. And I'm proud to say that now I'm BSDA certified! I've passed the exam with a quite high score, near the maximum, but I have to admit that I misread a few questions...I guess it is normal considering the stress of the exam itself.

I'm not supposed to talk about the exam contents, since one thing that any candidate has to sign and agree on is a non-disclosure agreement. However, I can say that the exam is very good in quality: questions are well written and, in my opinion, quite focused on the subject. Moreover, the correction of the question was in time, and therefore I received the results before the deadline for the correction has passed. 

How did I prepared to the exam? Well, I fired up four virtual machines, each one with one of the four mainstreams BSD releases (actually I was firing up five machines, but I used FreeBSD instead of PCBSD because I did not need a graphical environment to test my capabilities). On each machine I exercised all the confgurations and commands the BSDCG Study Guide recommends, and I noticed the differences among any command and stack. Being mainly a FreeBSD user, I found myself at home on FreeBSD systems, but recognized the need for more practice on different BSDs, and having virtual machine was a good way of comparing all the four main systems.

Central Europe BSD Day 2013

With a few days of delay I'm reporting my trip to Naples to participate to the Central Europe BSD Day 2013. The conference was well organized and the location was nice: the conference took place at the CNR in Naples, and we had a whole room with multimedia display where several very good speakers presented the current status in many BSD-related projects.

One interesting fact that emerged from the conference is that the BSD community is somewhat really small when compared to the Linux one, and this does not mean that it has lack of quality or is steps behind because of the lack of resources: on the other hand the BSD community (or better, all BSD communities) has been able to focus and exploit their resources at the best. In other words, even with less developers than other communities, BSD is able to ship an enterprise quality set of products. It sounds to me that the whole point in BSD is to keep things simple, so that they are easier to be managed.

With regard to the conference organization I have to say organizers were really nice and made a good job to make the day successful, even if the number of participant was not so big as I would have been expected from an European event. However, the conference place was good, the meat was great and the technical discussions were very interesting too, so I've nothing but good words to say about the event.

As a side note, I had the opportunity to leave a few PostgreSQL flyers and to talk to some people about both ITPUG and PostgreSQL.

FreeBSD kernel malloc

The FreeBSD kernel provides a set of malloc/free functions that are similar to the C-library ones for managing the memory inside the kernel space.

All the memory management is done using the malloc_type structure, that is defined as follows:

struct malloc_type {
   struct malloc_type *ks_next; /* Next in global chain. */
   u_long ks_magic; /* Detect programmer error. */
   const char *ks_shortdesc; /* Printable type name. */
   void *ks_handle; /* Priv. data, was lo_class. */
};

The first field is a pointer to another malloc_type structure used to chain the allocated memory descriptor in a list, in particular the kern_malloc.c contains a kmemstatistics struct that always points to the last allocated malloc_type structure (and hence to the head of the chain). The ks_magic field is used to check for wrong malloc'ed areas: if it does not contains the special value M_MAGIC the kernel will panic assuming the memory is corrupted. The ks_shortdesc contains a description of the memory area, as reported in the output of the command "vmstat -m". Finally, the ks_handle field contains another structure, malloc_type_internal that in turns contains private kernel data, such as DTrace probes, the zone from which the memory has been allocated and statistics about the memory area itself.

Therefore in order to handle a memory chunk in the kernel space a malloc_type struct must be hold. There are two main macros to deal with malloc_type, defined in the sys/malloc.h header file:

- MALLOC_DEFINE

- MALLOC_DECLARE

The former, MALLOC_DEFINE, is used to define an area of memory that will be allocated later using the malloc(9) call. The latter, MALLOC_DECLARE, is a shortcut for "importing" a memory definition into another source file.

The MALLOC_DEFINE macro is shown in the following:

#define MALLOC_DEFINE(type, shortdesc, longdesc) \
   struct malloc_type type[1] = { \
         { NULL, M_MAGIC, shortdesc, NULL } \
         }; \
   SYSINIT(type##_init, SI_SUB_KMEM, 
               SI_ORDER_SECOND, malloc_init, \
              type); \
   SYSUNINIT(type##_uninit, SI_SUB_KMEM, 
                    SI_ORDER_ANY, \
                    malloc_uninit, type)

The macro contains three instructions. The first is the declaration and initialization of a malloc_type structure as a single element array (this trick is done to have a pointer to the malloc type within the macro itself - the array name is the pointer to the malloc type). The other two instructions attach the malloc_init and malloc_uninit functions to the specified malloc type. In this way, the system will initialize (and uninitialize) the memory area with the above functions (from kern_malloc.c). The SI_SUB_KMEM subsystem is scanned and executed during the boot, and if the MALLOC_DEFINE happens to be in a module, the initialization and desctruction happens as soon as the module is loaded/unloaded. The "##" used in the macro is for macro token concatenation.

To better understand the above MALLOC_DEFINE macro, suppose the following is called in a module:

MALLOC_DEFINE( M_LUKE, "Luke Memory", 
               "Memory for the Luke subsystem" );

this will expand to:

struct malloc_type M_LUKE[1] = 
      { { NULL, M_MAGIC, "Luke Memory", NULL } };
SYSINIT(M_LUKE_init, 
          SI_SUB_KMEM, SI_ORDER_SECOND, 
          malloc_init, M_LUKE );
SYSUNINIT(M_LUKE_uninit, 
          SI_SUB_KMEM, SI_ORDER_ANY, 
          malloc_uninit, type);

The second macro for memory usage is MALLOC_DECLARE, that is defined in sys/malloc.h as follows:

#define MALLOC_DECLARE(type) \
extern struct malloc_type type[1]

and that is useful simply to inform that a piece of malloc-based memory metadata has been defined somewhere else in the source tree.

In order to conclude this brief bird's eye view on kernel memory allocation, the malloc_init and malloc_uninit functions defined in sys/kern_malloc.c perform calls to the uma_zalloc and uma_zfree_arg to respectively allocate and free a memory chunk. The zone used for the allocation is always the same, called mt_zone and created in the kmeminit function (executed of course early in the boot sequence):

static void
kmeminit(void *dummy)
{
...
mt_zone = uma_zcreate("mt_zone", 
           sizeof(struct malloc_type_internal),
           NULL, NULL, NULL, NULL
           UMA_ALIGN_PTR, UMA_ZONE_MALLOC);
...
}

The UMA related functions are defined in the vm/uma_core.c source file.

Calendar for fun

Il calendario di Unix/Linux prende i propri file da /usr/share/calendar. Esplorando tale directory si possono trovare alcuni file curiosi, come ad esempio:
- calendar.computer che contiene date storiche circa i computer
- calendar.lotr che contiene le date della saga Lord Of The Rings
- calendar. che contiene le date principali della propria distribuzione o del proprio sistema operativo (es. calendar.debian, calendar.freebsd)
- calendar.music che ovviamente contiene delle date storiche per la musica

Ad esempio, invocando calendar con il file lotr si ottiene:

$ calendar -f /usr/share/calendar/calendar.lotr
Apr 04  Gandalf visits Bilbo

Vale la pena visitare la directory per scoprire altri calendari interessanti!

make love, not war

Adoro la cultura Unix!
E adoro la possibilita' di inserire degli "easter egg" nei programmi, ovvero delle piccole sorprese, il piu' delle volte mirate a far sorridere l'utente o il sysadmin.

Ecco allora che il super-comando make, se invocato con il target speciale "love", risponde con il classico slogan. La versione GNU dei sistemi Linux e' invece piu' seria e rigorosa, e risponde con un messaggio di errore poiche' il target "love" non esiste...

 

Se si controlla il sorgente del make Unix, in particolare in job.c, si trova il seguente pezzo di codice che, ovviamente, spiega il funzionamento:

#ifndef WITHOUT_OLD_JOKE
                    if (strcmp(gn->name,"love") == 0)
                               (*abortProc)("Not war.");
                     else
#endif

Usare lo stesso UID fra account differenti

Alcuni sistemi Unix, come ad esempio FreeBSD, forniscono effettivamente due utenti root: il classico root e il suo rovesciato toor. Per verificare la presenza di questi due utenti e' sufficiente usare il seguente comando:

% grep "^[rt]oo[rt]:" /etc/passwd
root:*:0:0:Charlie &:/root:/bin/csh
toor:*:0:0:Bourne-again Superuser:/root:

L'idea e' semplice: root e' l'utente impostato all'atto dell'installazione e non dovrebbe mai essere personalizzato (ad esempio modificandone la shell), al fine di garantire che in situazioni estreme (es. single user mode) l'account funzioni come ci si aspetta (o meglio come si aspetta il sistema). Il suo rovescio, toor, e' invece un account che puo' essere personalizzato ad esempio impostando una shell differente (presa da /usr e non disponibile in single user mode).

Si noti che i due account condividono lo stesso UID (0) e quindi sono di fatto lo stesso account, solo con entry differenti nei vari database.

Oggi giorno non esiste piu' la reale necessita' di usare una simile tecnica, grazie a strumenti come sudo che consentono una personalizzazione di account utente normali estrema. Alcune distribuzioni Linux non forniscono nemmeno un account root disponibile, forzando l'utente a configurare sudo.

Ancora oggi pero' qualcuno e' tentato da usare questa tecnica dei doppi account per separare privilegi, personalizzazioni, ecc. La mia risposta breve e': NON FATELO!

In generale potrebbero esserci applicazioni che, stupidamente, ritengono che un UID sia unico. E queste si riveleranno sicuramente come una falla di sicurezza. Dopotutto, la generazione di /etc/passwd da /etc/master.passwd non e' per via di alcune applicazioni "stupide" che richiedono accesso al database degli utenti?

In secondo luogo, il sistema potrebbe confondersi, non facendovi vedere chi ha creato quali file:

# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
root@fb91:/root # touch test.txt
root@fb91:/root # ls -l test.txt
-rw-r--r-- 1 root wheel 0 test.txt

# su - toor
# touch test2.txt
# ls -l test2.txt
-rw-r--r-- 1 root wheel 0 Mar test2.txt

L'ownership dei file viene presa assumendo il primo record che si trova nel database (forse ls e' da considerarsi una applicazione stupida? In realta' non saprebbe come fare a discriminare gli utenti). Quindi condividere utenti/privilegi con questo metodo vi fa perdere, gratis e con effetto immediato, la tracciabilita' di quale utente ha toccato quali file.

La strada corretta per gestire in sicurezza i privilegi e' usare sudo.

portsnap patch to use fetch (instead of wget)

I did some review to my micro portsnap patch, thanks also to the suggestion on the FreeBSD forums and -stable mailing list.

In particular, as someone pointed out, using wget(1) is not a good idea because it is not part of the base system and requires an admin to manually install it from ports or packages. That is not a big deal in my opinion, and it is the reason why I made a change so that it was possible to configure, using /etc/portsnap.conf, a way to specify that wget(1) was required. To make it even clearer, I also created a function check_downloader that is used to check the presence of the program executable used to download stuff (either phttpget or wget).

I was not fully happy with such patch, but I have not a better idea until someone on the -stable mailing list pointed out that FreeBSD (of course!) has already a downloader: fetch(1).

The problem with fetch(1) is that it requires a full URL while portsnap was internally dealing with clean server names.

So I reverted the patch in order to avoid using wget(1) and to use fetch(1) by means of a flag in /etc/portsnap.conf and introduced a new variable in the internal portsnap implementation, SERVER_PROTOCOL, that simply handles "http" in the case of the usage of fetch(1).

The patch has moved into another path within my repository and is available here.

portsnap patch to use wget

portsnap is the tool used on FreeBSD to download the ports tree and to update it. Internally, portsnap uses phttpget to download the various files to work with. The problem of the latter is that it does not handle very well the http_proxy variable, that is set when behind an http proxy. Well, let's say, phttpget handles http_proxy very badly: when the http_proxy variable is in the form of

http_proxy="http://user:password@proxy:port"

the program does a very awkward parsing of the variable value getting the "password@proxy:port" as the proxy port, that is it gets confused by the colon within the string. This is of course very annoying and prevents the adoption of FreeBSD behind an http proxy. I searched by myself the solution for quite a lot, and finally I wrote a simple patch to portsnap to substitute the use of phttpget with wget, that handles normally the http_proxy variable.

The result is available on one of my git repositories and can be applied as follows (I suggest making a copy of portsnap into portsnap_wget):

cp /usr/bin/portsnap /usr/bin/portsnap_wget

patch -p0 /usr/bin/portsnap_wget portsnap_wget.diff

After that, and assuming of course that you have installed wget from either packages or ports, it is possible to use the portsnap_wget command as the usual portsnap to download updates either when behind a proxy or not:

portsnap_wget fetch update

With regard to the patch, it did not involved only changing the download program to wget, but also to change the definition of the files to download, that now are not passed via xargs but within a loop.

Shell Script Trick: command

In molti dei miei shell scripts utilizzo delle variabili per memorizzare la posizione assolutadei comandi che lo script andra' ad eseguire, come ad esempio:

#!/bin/sh

PERL_CMD=`which perl`

SED_CMD=$( which sed )

...

if [ -z "$PERL_CMD" ]

then

   echo "Perl executable not found!"

   exit 1

fi

if [ -z "$SED_CMD" ]

then

   echo "Sed executable not found!"

    exit 1

fi

...

Come si puo' notare lo script controlla le proprie dipendenze andando a verificare che ogni variabile/comando sia correttamente valorizzata, altrimenti significa che lo script non ha trovato uno dei comandi (non builtin) richiesti e quindi non puo' procedre.

Questa procedura e' abbastanza laboriosa e ha un problema di performance: ad ogni invocazione di which viene aperto un sottoprocesso che si occupa di cercare il comando specificato.

Grazie ad alcuni suggerimenti ho scoperto un comando builtin, command, che verifica e restituisce il percorso assoluto di un comando senza bisogno di lanciare sotto-processi, quindi con ovvio aumento di performance. Sostanzialmente il comando command si

preoccupa di cercare un programma in ogni entry del $PATH. Il codice quindi diviene:

#!/bin/sh

PERL_CMD=`command perl`

SED_CMD=$( command sed )

...

if [ -z "$PERL_CMD" ]

then

   echo "Perl executable not found!"

   exit 1

fi

if [ -z "$SED_CMD" ]

then

   echo "Sed executable not found!"

   exit 1

fi

...

GEOM naming

As far as I can understand reading the documentation and looking at the FreeBSD GEOM source tree, the naming scheme is as follows:

• each transformation specification is written upper-case;
• each transformation class is written lower-case;
• each module that defines and implements a class lacks the initial g;
• usually each device that is perceived as a provider uses the module name as a way of indicating the service, such has using an extension or being under a folder with the module name if the /dev directory;
• each file in the above module has the g_ prefix, followed by the class name (lower-case) and an optional suffix with a leading underscore.

So for instance, in the case of the disk encryption we have that:

• GELI (upper-case) specifies the transformation, that is the contract for the service;
• geli (lower-case) is the class implementation, that is the code that implements the above contract;
• eli is the module that contains the source code, that is the folder in the source tree;
• eli is the extension of an encrypted device (e.g., /dev/da0s1e.eli);
• each file in the above source tree is named g_eli with an optional suffix.

As another example consider the mirroring facilities:

• GMIRROR is the transformation;
• gmirror is the class implementation;
• mirror is the module that contains the source code for the class implementation;
• usually mirrors are under /dev/mirror;
• each file is named g_mirror and something more.