Developing an Android driver that can count words (2)

5. Specify driver-related information

Although it is not necessary to specify this information, a complete Linux driver will specify this driver-related information. Generally, the following information needs to be specified for a Linux driver.

1. Module author: specified using the MODULE_AUTHOR macro.

2. Module description: specified using the MODULE_DESCRIPTION macro.

3. Module alias: specified using the MODULE_ALIAS macro.

4. Open source agreement: use MODULE_LICENSE macro to specify.

In addition to this information, the Linux driver module itself also contains some information. Readers can execute the following command to view the information of word_count.ko.

# modinfo word_count.ko

After executing the above command, the information shown in Figure 6-6 will be output. Depends indicates the dependencies of the current driver module. Word_count does not depend on anything, so this item is empty. Vermagic indicates the Linux kernel version under which the current Linux driver module is compiled.

Now use the following code to specify the above 4 types of information. Generally, these codes are placed at the end of the word_count.c file.

MODULE_AUTHOR("lining");

MODULE_DESCRIPTION("statistics of wordcount.");

MODULE_ALIAS("word count module.");

MODULE_LICENSE("GPL");

Now use the method in the previous section to recompile the word_count.c file. Then execute the modinfo command, and the information shown in Figure 6-7 will be displayed. As can be seen from Figure 6-7, the information set by the above code is included in the word_count.ko file.

6. Open Source Agreement

Although many individual developers or small companies do not consider the restrictions of open source agreements, larger companies may be at risk of being sued if they violate open source agreements. Therefore, companies with a certain scale and influence must pay attention to the open source agreements used by these software when using open source software.

In order to reduce the difficulty of publishing Linux drivers and the size of the installation package, many Linux drivers are open source. In the Linux driver source code, the MODULE_LICENSE macro is used to specify the open source agreement. For example, the word_count driver uses the GPL agreement. So what agreement should we adopt when writing Linux' drivers? There are many open source agreements at present. Readers can go to the following page to view all open source agreements.

http://www.opensource.org/licenses/alphabetical

The following is an introduction to the basics of the five most commonly used open source protocols. For details of these five open source protocols and other open source protocols, please refer to the relevant pages of the Open Source Initiative organization.

GPL License

Programmers who like to delve into technology should like the GPL agreement very much. This is because the GPL agreement forces software that uses the open source agreement to be open source. For example, the Linux kernel uses the GPL agreement. The starting point of GPL is free/open source. But unlike other open source agreements (such as BSD, Apache Licence), the GPL agreement is more thorough in open source. Not only does it require software that uses the GPL agreement to be open source/free, but it also requires its derivative code to be open source/free. For example, software A uses the GPL agreement, and software B uses software A, so software B must also be free/open source. And its software B must also use the GPL agreement. Software C uses software B, so software C must also be open source/free, and of course, software C must also use the GPL agreement. This is the so-called "contagiousness." This is also the reason why there are many Linux distributions and other software that use the GPL agreement that are open source.

Since the GPL agreement strictly requires that software products using the GPL agreement must use the GPL agreement and must be open source/free. For commercial software or departments that have confidentiality requirements for code, it is not suitable to use the GPL agreement to release software or reference libraries based on the GPL agreement. In order to meet the needs of commercial companies and confidentiality, the LGPL agreement emerged on the basis of the GPL agreement.

LGPL

LGPL is an open source protocol designed mainly for class libraries. Unlike GPL, which requires that any software that uses/modifies/derives from GPL class libraries must adopt the GPL protocol. LGPL allows commercial software to use LGPL class libraries through class library references (links) without the need to open source the commercial software code. This allows open source code using the LGPL protocol to be referenced, published, and sold by commercial software as a class library.

However, if you modify or derive the LGPL-licensed code, all modified code, additional code involved in the modified part, and derived code must use the LGPL protocol. Therefore, the LGPL-licensed open source code is very suitable for being referenced by commercial software as a third-party class library, but it is not suitable for commercial software that wants to use the LGPL-licensed code as a basis for secondary development through modification and derivation.

BSD License

The BSD open source protocol is a protocol that gives users great freedom. Basically, users can "do whatever they want", they can freely use and modify the source code, and they can also release the modified code as open source or proprietary software. However, the premise of "doing whatever you want" is that when you release the code using the BSD protocol, or when you use the BSD protocol code as the basis for secondary development of your own products, you need to meet the following three conditions.

1. If the redistributed product contains source code, the source code must contain the BSD license in the original code.

2. If you are only releasing a binary library/software, you need to include the BSD license in the original code in the library/software documentation and copyright statement.

3. You may not use the name of the author/institution of the open source code or the name of the original product for marketing purposes.

The BSD protocol encourages code sharing, but it is necessary to respect the copyright of the source code author. BSD allows users to modify and republish code, and also allows the use or development of commercial software on BSD code for release and sale, so it is a very friendly protocol for commercial integration. Many companies and enterprises prefer the BSD protocol when choosing open source products, because they can fully control these third-party codes and can modify or redevelop them when necessary.

Apache License 2.0

Apache Licence is a license adopted by the famous non-profit open source organization Apache. This license is similar to BSD, and also encourages code sharing and respects the copyright of the original author. It also allows code modification and re-release (as open source or commercial software). The conditions that need to be met are also similar to BSD.

1. You need to give the user of the code an Apache License

2. If you modify the code, you need to indicate it in the modified file.

3. The extended code (modified and derived code from the source code) must include the original code's agreement, trademark, patent statement and other instructions required to be included by the original author.

4. If the re-released product contains a Notice file, the Apache Licence must be included in the Notice file. You can add your own license in the Notice, but it cannot be expressed as an Apache Licence.

Apache Licence is also a commercial application-friendly license. Users can also modify the code to meet their needs when necessary and publish/sell it as open source or commercial products.

MIT Protocol

MIT is a loosely restricted license like BSD. The author only wants to retain copyright without any other restrictions. In other words, you must include the original license statement in your distribution, whether you release it in binary or source code.

7. Register and unregister device files

This section will create a device file for the word_count driver. The name of the device file is wordcount and it is located in the /dev directory. Device files are different from ordinary files. They cannot be created using IO functions. Instead, they need to be created using the misc_register function and deregistered (removed) using the misc_deregister function. The definitions of these two functions are as follows:

Generally, it is necessary to create a device file when initializing the Linux driver and delete the device file when uninstalling the Linux driver. In addition, the device file also requires a structure (miscdevice) to describe the information related to it. There is an important member variable fops in the miscdevice structure, which is used to describe the function pointer of the device file in various triggerable events. The data type of this member variable is also a structure file_operations.

In this section, you need to modify the word_count_init and word_count_exit functions of the word_count.c file and define some macros and variables. The modified code is as follows:

There are a few things to note when writing the above code: