Re: link-sets in modules

[Paul Goyette <paul%whooppee.com@localhost>]

I'm not sure this solves the problem.

From my earlier attempts at modularizing the ieee80211 code, it seems 
that there are two separate mechanisms for finding the start and end of 
a link set:

1. Within a monolithically-linked kernel, we have the symbols
   __{start,stop}_link_set_* but no program section table

2. Within a module, we have the program section table (containing a
   start address and size), but no symbols

Since the primary purpose of link_sets is to gather together some 
unknown quantity of "info" from arbitrary contributors without imposing 
any restrictions on quantity, I don't see how your proposal addresses 
the need of figuring out the size/quantity portion of the equation.



I _do_ like part 2 of your proposal - linking the "core" kernel first, 
and then re-linking with selected modules.




On Mon, 28 May 2012, David Laight wrote:

> There are currently problems loading modules that contain link-sets
> (link-sets were the 'flavour of the month' a while back!) because
> the link sets don't get processed during module load (and unload)
> because they are processed by the initialisation of other code.
>
> I think the following will fix this and thus allow the same driver
> object to be run either as a loaded module, or linked into the main
> kernel.
>
> 1) Add another link-set describing each link-set. At a minumum containing
>   the name of the link-set, and functions to process the addition and
>   removal of data areas.
>
> 2) When the module-loader is loading a module and finds a link-set
>   (which is how it finds the module info itself), it searches the
>   known link-set processors (from the link-set defined in (1) and
>   any added later) and calls the relevant function to proces the
>   entries.
>
> I think the link-set functions need initialising after the module's
> own initialisation - unless that is a property of the link-set?
>
> The module loader will need to remember the link sets info for
> module unload.
>
> That should make it easier to build some bits as modules.
>
> I have an aim that the kernel build be changed slightly:
> 1) build all the 'modules' *.kmod.
> 2) run 'config' and compile a kernel that excludes all the modules
>   but leave the final link as an 'ld -r' generating a netbsd.o.
> 3) Link some or all of the *.kmod into netbsd.o
> 4) A final link generating a fully fixed-up netbsd.
> 5) Release *.kmod and netbsd.o (as well as netbsd).
>
> This would make it easy to remove a lot of 'unusual' drivers from
> the kernel, while still making is easy to add them into a bootable
> kernel for systems that need them at boot time.
>
> Thoughts/comments ?
>
>         David
>
> --
> David Laight: david%l8s.co.uk@localhost
>
> !DSPAM:4fc320902401490139417!

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------