Tightening symbol exports
Tightening symbol exports
Posted Nov 29, 2007 13:22 UTC (Thu) by IkeTo (subscriber, #2122)In reply to: Tightening symbol exports by simlo
Parent article: Tightening symbol exports
From the point of view of developers who want to use these functions, I see your point. But from the point of view of developers who actually write these functions, I think it is totally unacceptable to export all symbols. What it means is that you don't know what you will break when you make whatever modification. In other words, with the EXPORT_SYMBOL mechanism, developers can at least have some idea about what will break by the changes they want to make, so they can try their best to minimize breakage and plan them ahead when needed. Without the mechanism, all they can do is to break their interface completely randomly, which I don't see is a good service to module writers. While the EXPORT_SYMBOL mechanism does have rough edges, I think it is essential for keeping things maintainable even though the kernel functions/interfaces are made and used by people who are not known to each other.
Posted Nov 29, 2007 14:06 UTC (Thu)
by simlo (guest, #10866)
[Link] (1 responses)
Posted Nov 29, 2007 14:54 UTC (Thu)
by IkeTo (subscriber, #2122)
[Link]
Tightening symbol exports
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.
Tightening symbol exports
> As there specifically is no stable API to outside drivers you do not have
> to think about breaking stuff outside the kernel anyway.
I think most people would consider a symbol involved in EXPORT_SYMBOL to be "somewhat stable",
i.e., yes it breaks from time to time, but nobody would expect it to break every minor kernel
version. Also, such a mechanism would save developer from having to search in the whole
kernel source tree after making whatever minor change to function prototypes.
> 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).
I don't think this is a case for any technical reason: after all, kernel modules can easily be
loaded with user-mode helpers which will resolve all the symbols needed, and the symbol
information is easily made available if not already available via the System.map.