tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: link-sets in modules



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


Home | Main Index | Thread Index | Old Index