Re: the cost of EXPORT_SYMBOL_GPL

[Tomek The Messenger <tomekthemessenger@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3437 bytes --]

OK, so I had to wrongly described something because in my company this is
popular approach to use /sys as some abstract layer to get access to
registers.
So maybe in other words.
Let's say You have many socs. In one soc reset_reason can be gotten from
devmem 0xfff.... In other soc reset_reason can be gotten through i2c read
from some device.
Apart from reset_reason You have many other functionalities like kernel
boot source (tftp, spi).
And let's assume you are tester. It is hard for those people to remember
addresses, remembering and checking all the time how to read reset_reason
or routing, then extract value from proper bits. Instead of raw addresses
they have interface in /sys in the form of files. For example they read
cat /sys/resetreg/reason
as output they got in string format for example COLD_REBOOT.
They read:
/sys/bootreg/source
As output they got in string format TFTP.
And that is on each soc. This is good that registers, the way of access is
hidden under interface. It is easier and faster to debug anything with such
approach even for developers not only testers.
And there is separate kernel module which implements read/write access to
each of directory in /sys. So we use here linux API:
kobj = kobject_create_and_add("bootreg", NULL);
sysfs_create_groups(kobj, ...)
So hope that You have now good understanding.
I cannot show the code as I don't if I am allowed. I am about half an year
in kernel development team, so sometimes I have some doubts. And now my
doubts are where to put API for read/write operations as I mentioned above.

On Wed, Jun 17, 2020 at 10:55 AM Greg KH <greg@kroah.com> wrote:

> On Wed, Jun 17, 2020 at 09:58:03AM +0200, Tomek The Messenger wrote:
> > Hi
> > Thanks for reply.
> > We make some proxy layer in linux /sys. So for example we have
> directories:
> > /sys/resets
> > /sys/routers
>
> Really?  That's a total abuse of sysfs, don't do that.
>
> Seriously, that's not ok at all.
>
> > 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?
>
> I really do not understand at all, sorry.  Why are you using sysfs for
> something that it is not designed for?  And sysfs directory structure
> has nothing to do with kernel module names/structures.
>
> Do you have a pointer to your code somewhere so that we can review it
> and suggest the correct apis you should be using instead?
>
> thanks,
>
> greg k-h
>

[-- Attachment #1.2: Type: text/html, Size: 4079 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

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