GSoC 2015 RPi USB Support

[Chris Johns]

On 9/07/2015 5:38 am, Sebastian Huber wrote:
> 
> You have to figure out how the linker set mechanism works in general.
> 

The following is a simplified view of the 'linker set' mechanism.

The idea is similar to C++ static constructors and destructors without
compiler and linker support automatically managing the process. The end
result of the 'linker set' process is to create a section of the
executable memory that is an array of values, usually pointers, to the
data being managed. The run-time code knows how to find this section of
memory and how to process the data it contains. The feature uses
specially name ELF sections.

The reason 'linker sets' exist and the need for the complexity can be
seen by considering a simple example. Lets say you have a statically
linked ELF application called 'app' that consists of a single ELF object
file called 'a.o' linked to 'fb.o' (for FreeBSD). You can link this
executable and have no unresolved external symbols. When you run this
executable and it looks for specific resources there are none because
you did not link any. You now build module 'm.o' and driver 'd.o' and
add these to the linker command line. Again the executable links without
error and this time when you run it you can find the resources present
in 'm.o' and 'd.o'.

How can an executable that originally linked without any unresolved
externals make calls and see resources in the module and driver code by
just linking them ? There cannot be any static calls to the module or
driver code or we would have seen the unresolved externals, yet some how
those object files have automatically bound themselves to the system at
run-time and their resources have become available.

The 'linker sets' do this. By linking the module and driver object files
the specific data they have gets included in the specific linker 'set'
and so the generic code in the 'fb.o' object file can see it and make
the needed calls to the module and driver code so the resources
contained in them become available.

This architecture is really neat and has been implemented nicely in
FreeBSD. It means FreeBSD can bind new sub-systems and drivers into the
kernel without having to have complex and hard to maintain conditionals
in the code based on magic compile time defines. All they do is compile
the needed parts and link what is needed. A different hardware
architecture is a different set of object files.

Chris