2.2. Affix architecture

Generally Affix software can be divided into two components (according to protocol stack):

The general software architecture is shown on Figure 2-2

Figure 2-2. Affix architectural model

The philosophy of the Unix (and Linux) operating system is the following that the kernel should provide basic mechanisms and the user space applications should implement logic [STEV97]. The bottleneck of this approach is problem of performance. In this case it is possible to move some functionality from the user space to the kernel space. The only reason to put more functionality to the kernel space is to increase the performance of the system.

Other key benefits of having more functionality in the user space are easier implementation process for the user space and greater stability of the system, which is less likely to crash due to bugs in the applications. It is possible to use wider range of debugging facilities.

According to the philosophy of the Unix operating system the most appropriate way to implement basic Bluetooth protocol stack to be running in the kernel space and ME to be running in the user space. Affix follows this concept.

The Bluetooth protocol stack has predefined functionality and is defined in the Bluetooth system specification. The protocol stack of different systems should have the same functionality. Otherwise interoperability is not guaranteed.

All network data traffic comes to Affix from the kernel space. Thus optimal solution for performance reason is to implement core protocols in the kernel space.

The ME has to complement the Bluetooth protocol stack functionality and can have additional functionality depending on the goal of the system. It is implemented as a user space application. The performance is not very critical here. In this case it is possible to re-implement the ME without modifying the kernel space code.

Practical Affix component diagram is shown on Figure 2-3.

Figure 2-3. Affix components