Thanks for reply.

We make some proxy layer in linux /sys. So for example we have directories:

/sys/resets

/sys/routers

etc.

So if user wants to get to know what is the reset reason he doesn't use devmem 0xfff...., he just read the file in /sys/resets/..

If user wants to know some routing path he doesn't read registers via devmem, he only reads some file in /sys/routers which gives him output.

So this is in order to facilitate reading/writing to registers. Instead of searching in documentation concrete registers users have some helper proxy layer in sysfs. And for each directory in /sys there is separate kernel module. Division is based on some functionalities like resets, routing etc.

And the problem is should this 6th kernel module perform role of getting access to all registers or only to parts which are used by more than one kernel module? Now I am using second approach but when I am looking at the code it looks terrible. For example #define for register X and function to access it, is in module A, for egister Y in module B, for register Z in 6th kernel module. There is mess I think and maybe better approach is to put all API to 6th kernel module?

wt., 16.06.2020, 15:27 użytkownik Greg KH <greg@kroah.com> napisał:

On Tue, Jun 16, 2020 at 03:18:02PM +0200, Tomek The Messenger wrote:
> 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.

Why is this so many different modules? Why not just make it one?

thanks,

greg k-h