the cost of EXPORT_SYMBOL_GPL

[Tomek The Messenger]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200616/7d0a5d8a/attachment.html>