the cost of EXPORT_SYMBOL_GPL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi
I am in the middle of implementation of various external kernel modules.
All kernel modules touch some board specific registers. For example let's say we have 3 groups of register areas:
#define REG1_ADDR (0xFDEA7000)
#define REG1 _SIZE (0x3C0)
#define REG2_ADDR (0xFDEC4000)
#define REG2 _SIZE (0xFF8)
#define REG3_ADDR (0xFDEA6000)
#define REG3_SIZE (0x80)
And let's say we have 5 kernel modules:
A
B
C
D
E

Kernel module A touches only one 32-bit register X from REG1 space and a lot of registers from REG2 space. 
Kernel modules B,C,D touches various registers from REG1 and REG2 space but not this one which kernel module A touches.
Kernel module E is the only one who touches registers from REG3 space. No other kernel module touches REG3 space.

If I would implement the code in C++ in user space I would create dynamic library for access to REG1,REG2,REG3 register space. Each 32-bit register would have his own separate function to read,write to register. And then each user space process A-E would be linked against this library during compilation.
When programming in kernel I don't know what I should do.
Should I implement 6th external kernel module which implements all operations on access to registers REG1,REG2,REG3??? There will be a lot of EXPORT_SYMBOL_GPL. Or maybe this approach is NOK, I mean it is good but I should only place in 6th helper kernel module functions which are used by more than one kernel module. So for example functions for getting access to REG3 address space or reg X from REG1 space should be not there. They should be only in kernel module code A/E. Currently this is code which I implemented. In 6th helper kernel module there are only registers which are used by more than one kernel module. But I am not sure if it is good approach. Maybe there should be there all registers access?

Could anybody help how to organize code here. 

BR
Tomek

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]

  Powered by Linux