Messages in this thread | | | From | Rusty Russell <> | Subject | Re: Rusty's module talk at the Kernel Summit | Date | Thu, 11 Jul 2002 15:13:02 +1000 |
| |
In message <Pine.GSO.4.21.0207102311290.6250-100000@weyl.math.psu.edu> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |