CODEWITHSUNDEEP
linuxlinux-kernelkernellinux-device-driverembedded-linux
ayoubsvbri
ayoubsvbri

Reputation: 35

Driver's source code structure requirements for Linux Kernel upstream

I am planning to rewrite my sensor's driver in order to try to get my module in the Linux Kernel. I was wondering whether there were requirements regarding the organization of the source code. Is it mandatory to keep all the code in one single source file or is it possible to split it up in several ones?

I would prefer a modular approach for my implementation, with one file containing the API and all the structures required for the Kernel registration, and another file with the low level operations to exchange data with the sensor (i.e. mysensor.c & mysensor_core.c).

What are the requirements from this point of view?

Is there a limitation in terms of lines of codes for each file?

Note:

I tried to have a look at the official github repo and it seems to me that the code is always limited to one single source file.

https://github.com/torvalds/linux/tree/master/drivers/misc

Upvotes: 1

Views: 223

Answers (1)

Ian Abbott
Ian Abbott

Reputation: 17513

Here is an extract from "linux/drivers/iio/gyro/Makefile" as an example:

# Currently this is rolled into one module, split it if
# we ever create a separate SPI interface for MPU-3050
obj-$(CONFIG_MPU3050) += mpu3050.o
mpu3050-objs := mpu3050-core.o mpu3050-i2c.o

The "mpu3050.o" file used to build the "mpu3050.ko" module is built by linking two object files "mpu3050-core.o" and "mpu3050-i2c.o", each of which is built by compiling a correspondingly named source file.

Note that if the module is built from several source files as above, the base name of the final module "mpu3050" must be different to the base name of each of the source files "mpu3050-core" and "mpu3050-i2c". So in your case, if you want the final module to be called "mysensor.ko" then you will need to rename the "mysensor.c" file.

Upvotes: 1

Related Questions