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: [email protected]
!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 |
-------------------------------------------------------------------------
