User: Password:
|
|
Subscribe / Log in / New account

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.


(Log in to post comments)

Tightening symbol exports

Posted Nov 29, 2007 14:06 UTC (Thu) by simlo (guest, #10866) [Link]

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

Posted Nov 29, 2007 14:54 UTC (Thu) by IkeTo (subscriber, #2122) [Link]

> 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.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds