Re: Rusty's module talk at the Kernel Summit

[Rusty Russell]

In message <[e-mail]> you write:
> > So this TLB argument alone is not sufficient :-)
> > I do concur on the "ipv4 as module is difficult to
> > get correct" argument however.
> 
> Sure, but consider the amount of tricky modules and amount of easy ones.
> net/ipv4/*.c _is_ tricky; so much that having system with many parts of
> such complexity would be extremely painful.
> 
> IOW, yes, we have some very tricky interfaces between the parts of kernel;
> and their trickiness alone guarantees that we don't want to have them
> breeding.  Stuff that genuinely needs complex interfaces is *not* something
> you want to be mass-produced.

Sure, if you want to reduce the problem space to "modules which are a
single fs/net/etc device driver" then we can *definitely* work
something out.  This works because they have such a narrow and
non-time-critical interface (who cares if we do a gratuitous
atomic_inc on every fs mount?).

To really get this to work well, you should make sure such modules
don't even need init and remove functions, by providing something
like:

	I_AM_A_FILESYSTEM_DRIVER("ramfs", ramfs_fs_type);

> I'd rather get the simple (== large) classes into decent shape and then
> deal with what's left.  FVO "deal" possibly including "no rmmod for these
> guys".

This was *entirely* my question at the Kernel Summit:

	Are modules first class citizens?
	  Should everything be modular?
	  What complexity are we prepared to pay?

We *can* do anything, up to and including modules which hand out
references to themselves in interrupt context, and dealing with the
race between "my module count is zero" and "oops, someone jumped in
before I had deactivated myself" without using try_inc_mod_count.

But *should* we?  The solution, for those of strong stomach, looks
something like this:

	Each module implements: init(), start(), stop(), reinit(), destroy().
	Each registerable interface takes a "struct module *" parameter.
	Every call through a function ptr does "inc_mod_count(struct->module)"
		(Of course, if you make assumptions about a struct
		containing only functions from the same module or
		in-kernel ones, and knowing that some strategy
		functions are always called before others, you can
		optimize this).

I don't think we're disagreeing, but I did want to clarify,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.