Create a new macro for static DPCPU data

[andrew]

Summary

On arm64 (and possible other architectures) we are unable to use static
DPCPU data in kernel modules. This is because the compiler will generate
PC-relative accesses, however the runtime-linker expects to be able to
relocate these.

In preperation to fix this create two macros depending on if teh data
is global, or static.

[emaste]

LGTM

[bz]

Add you two for the DPCPU (and later VNET) static file local load relative issue (1st step) solution.

[emaste]

I'm fine with this as a NFC first step

[markj]

Looks like dpcpu(9) needs to be updated.

[bz]

What about (what do others think):

• leave the non static and not rename them to *_GLOBAL_*
• rename the static to STATIC_DPCPU_DEFINE

That way grep()ing for DPCPU_DEFINE will still give us all of them, there's less noise in the change, and only the problematic case is (will be) dealt with.

As @andrew will point out his version will make people less likely put static before a DPCPU_GLOBAL_DEFINE(); not sure if that's worth the trouble.

A similar change for VNET will be about 250 globals (touched or untouched) and 350 statics that will need changing.

I should add that should we find a more elegant solution where we can automatically handle the cases using the compiler/linker bits, we would have to undo less?

Discuss!

[markj]

In D16140#342262, @bz wrote:

What about (what do others think):

• leave the non static and not rename them to *_GLOBAL_*
• rename the static to STATIC_DPCPU_DEFINE

That way grep()ing for DPCPU_DEFINE will still give us all of them, there's less noise in the change, and only the problematic case is (will be) dealt with.

I like this better, but think it should be DPCPU_DEFINE_STATIC instead.

As @andrew will point out his version will make people less likely put static before a DPCPU_GLOBAL_DEFINE(); not sure if that's worth the trouble.

Can we define the macro so that the use of "static" results in a compile error? e.g.,

#define DPCPU_DEFINE(t, n) struct __hack; t DPCPU_NAME(n) ...

A similar change for VNET will be about 250 globals (touched or untouched) and 350 statics that will need changing.

I should add that should we find a more elegant solution where we can automatically handle the cases using the compiler/linker bits, we would have to undo less?

Discuss!

[emaste]

In D16140#342262, @bz wrote:

What about (what do others think):

• leave the non static and not rename them to *_GLOBAL_*
• rename the static to STATIC_DPCPU_DEFINE

That way grep()ing for DPCPU_DEFINE will still give us all of them, there's less noise in the change, and only the problematic case is (will be) dealt with.

Hrm, I can see the logic in that approach. What about DPCPU_DEFINE_STATIC or DPCPU_DEFINE_LOCAL instead, for the static-including one?

As @andrew will point out his version will make people less likely put static before a DPCPU_GLOBAL_DEFINE(); not sure if that's worth the trouble.

This seems like something we could include in a set of some sort of local lint rules; anyway I don't see it as a big deal - most likely folks adding new ones will cut and paste an existing example.

[andrew]

Rename the static macro to DPCPU_DEFINE_STATIC
Keep DPCPU_DEFINE, but make it a compile time error to use it with static

Stil todo: Update the man page

[emaste]

sys/sys/pcpu.h

84

maybe a comment to explain the use of struct _hack;

[bz]

Happy with those bits if you do the man page as you say :)

[andrew]

Add a comment on why struct _hack
Update the man page

[emaste]

Fine with me

[bz]

do whatever you want with the comment and commit