In practise EXPORT_SYMBOL has the complete opposit effect: Developers remove EXPORT_SYMBOL and a lot of stuff breaks even though there is no _technical_ reason for it to break. The rule when doing a change to the kernel is: You have to be able to compile the kernel and all drivers after you changed stuff (which of course is unrealistic as that involves all architectures, but I do hope that it is done before any "official" release.) The presence of EXPORT_SYMBOL doesn't change that, there could still be non-module stuff which depends on what you are changing. As there specifically is no stable API to outside drivers you do not have to think about breaking stuff outside the kernel anyway. The whole issue of using EXPORT_SYMBOL to limiting access is wrong. It was probably made to avoid exporting everything for mere technical reasons (limiting memory). Using the same mechanism to limit access is one of the typical hacks where you have one mechanism and abuse it for something else. In the long term that kind of stuff only give problems. I simply can't see why the access problem should in any way be related to the module boundary. What you want is something along "public", "protected", "package". The one way I know to do that in C is to take care about declaring the things in the right header files. Notice that even Microsoft didn't connect public memmbers in C++ classes with DLL_EXPORT or visa versa. The two things are orthogonal properties.
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds