the cost of EXPORT_SYMBOL_GPL

[Tomek The Messenger]

Maybe some pseudo-code:
So in other to implement file /sys/resetreg/reason You have to write:

static ssize_t reason_show(struct kobject *kobj,
struct kobj_attribute *attr, char *buf)
{
u32 val;

val = some_readAPI_to_get_reboot_reason();

return scnprintf(buf, PAGE_SIZE, "%d\n", (u32)(val));
}

static struct kobj_attribute reason = __ATTR_RW(reason);

static struct attribute *reason_attrs[] = {
&reason_attribute.attr,

NULL,
};
ATTRIBUTE_GROUPS(some_group);

Then this some_group symbol goes as second parameter to sysfs_create_groups.
So functions *_show go to separate kernel modules. But function
some_readAPI_to_get_reboot_reason() I think should be placed in 6th kernel
module, so in kernel module with read/write specific operations to given
soc.

On Wed, Jun 17, 2020 at 11:17 AM Tomek The Messenger <
tomekthemessenger at gmail.com> wrote:

> 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 at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200617/57100a82/attachment-0001.html>