1 Technical Background
In the Linux system, the kernel manages core resources (CPU scheduling, memory management, device control, etc.), while user space interacts with the kernel through system calls. Kernel modules serve as dynamic expansion mechanisms, enabling runtime loading of functionalities. **Drivers**, as specialized kernel modules, manage hardware devices (e.g., character devices, block devices, network devices). This article demonstrates the driver development workflow in a goldfish kernel environment, applicable to various server deployments (including testing on Hong Kong Servers or Hong Kong Cloud Servers).
—
2 Kernel Module Development
**2.1 Minimal Module Implementation**
A kernel module requires defining initialization/cleanup functions registered via `module_init`/`module_exit`:
“`c
#include <linux/init.h>
#include <linux/module.h>
static int __init hello_init(void) {
printk(“hello_kernel: Module loaded\n”);
return 0;
}
static void __exit hello_exit(void) {
printk(“hello_kernel: Module unloaded\n”);
}
module_init(hello_init);
module_exit(hello_exit);
MODULE_LICENSE(“GPL”);
“`
– The `__init`/`__exit` macros optimize memory: initialization code is auto-released after execution.
**2.2 Compilation and Loading**
– **Build into Kernel**:
1. Place code under `drivers/misc/demo/`, configure `Kconfig`:
“`
config HELLO_KERNEL
tristate “Hello kernel”
default y
“`
2. Modify `drivers/misc/Makefile`:
“`
obj-$(CONFIG_HELLO_KERNEL) += demo/
“`
3. Recompile kernel: `make`, generating `bzImage`.
– **Compile as Module**:
1. Set `default m`, compile the module:
“`bash
make M=drivers/misc/demo modules # Generates hello_kernel.ko
“`
2. Push to device and load:
“`bash
adb push hello_kernel.ko /data/local/tmp/
adb shell insmod /data/local/tmp/hello_kernel.ko
“`
3. Verify logs: `dmesg | grep hello_kernel`.
—
3 Driver Development: Character Devices
**3.1 Miscdevice Driver**
Utilizes a fixed major number (10) to simplify character device development:
“`c
#include <linux/miscdevice.h>
#include <linux/fs.h>
#define DEVICE_NAME “hello_device”
static char str_buffer[128];
static size_t str_len;
// File operations interface
static struct file_operations hello_fops = {
.owner = THIS_MODULE,
.open = hello_open,
.release = hello_release,
.read = hello_read,
.write = hello_write,
};
// Register misc device
static struct miscdevice hello_misc = {
.minor = MISC_DYNAMIC_MINOR,
.name = DEVICE_NAME,
.fops = &hello_fops,
};
// Initialization (driver loading)
static int __init hello_init(void) {
misc_register(&hello_misc); // Creates device node /dev/hello_device
return 0;
}
“`
**Key Functions**:
– `copy_from_user()`: Transfers data from user space to kernel space.
– `copy_to_user()`: Transfers data from kernel space to user space.
**3.2 Testing and Validation**
1. **Terminal Read/Write Tests**:
“`bash
echo “test” > /dev/hello_device # Triggers write()
cat /dev/hello_device # Triggers read()
“`
2. **Application Layer R/W (Android Example)**:
“`kotlin
fun writeToDevice(data: String) {
FileOutputStream(“/dev/hello_device”).use { it.write(data.toByteArray()) }
}
fun readFromDevice(): String {
return FileInputStream(“/dev/hello_device”).readBytes().toString()
}
“`
> **Permission Handling**:
> “`bash
> chmod 666 /dev/hello_device # Grants R/W permissions
> setenforce 0 # Disables SELinux (test env)
> “`
—
**4 Deployment and Use Cases**
– **Test Environment**:
– Load goldfish kernel in Android emulator:
“`bash
emulator -avd Pixela10 -kernel arch/x86_64/boot/bzImage
“`
– **Production Environment**:
– Drivers can be deployed in cloud services like Hong Kong VPS or Hong Kong Servers for hardware support.
– **Technical Value**:
– Embodies Linux’s “Everything is a file” philosophy, unifying hardware management via `/dev` nodes (e.g., serial port `/dev/ttyS0`, Binder driver `/dev/binder`).
—
**5 Summary**
This guide demonstrates:
1. **Kernel Module**: Implements a dynamically loadable/unloadable `hello_kernel` module.
2. **Character Device Driver**: Develops a misc device `/dev/hello_device` supporting R/W operations.
3. **Cross-Space Communication**: Securely transfers data using `copy_from_user`/`copy_to_user`.
Future work can extend to real hardware drivers, customizable for cloud environments (e.g., Hong Kong Cloud Servers).
> **Appendix: Driver Interaction Sequence**
> “`
> User write() → Syscall → VFS → hello_write() → copy_from_user()
> User read() → Syscall → VFS → hello_read() → copy_to_user()
> “`