Re: [PATCH] 2.5.1-pre10 #ifdef CONFIG_KMOD Cleanup Part II.

From: Oliver Xymoron (oxymoron@waste.org)
Date: Sat Dec 15 2001 - 11:58:44 EST


On Sat, 15 Dec 2001, Rusty Russell wrote:

> In message <Pine.LNX.4.40.0112141019100.11489-100000@waste.org> you write:
> > On Thu, 13 Dec 2001, Rusty Russell wrote:
> >
> > > 2) Adds request_module_start()/request_module_end() macros, eg.
> > >
> > > struct protocol protoptr;
> > >
> > > request_module_start("proto-%u", protonum) {
> > > /* search for protocol, set protoptr. */
> > >
> > > } request_module_end(protoptr != NULL);
> > >
> > > This loops once if !CONFIG_KMOD or protoptr != NULL after first
> > > iteration, otherwise calls request_module and loops a second time.
> >
> > Clever, but very un-C-like. Perhaps something like this:
> >
> > do {
> > /* search for protocol, set protoptr. */
> > } while (protoptr != NULL || request_module("proto-%u",protonum)==0);
> >
> > ..with request_module returning -EBUSY if the module is already loaded.
>
> This can spin forever 8(.

Well there is a thinko or two above, but provided we have a variant of
request_module that only returns zero when it actually loads a module,
this should only loop once or twice:

 do {
   /* search for protocol, set protoptr. */
 } while (protoptr == NULL && request_module("proto-%u",protonum)==0);

> > > 3) Adds a request_module_unless() macro, eg:
> > >
> > > protoptr = request_module_unless(protoptrs[proto],
> > > "proto-%u", protonum);
> >
> > Also weird.
>
> Ack. However, I was looking for positive suggestions 8)

I think the deeper problem is that request_module is expensive. If, say,
it had a fast path on the order of an inline hash lookup on a cookie
corresponding to the module identifier, we could just unconditionally
request_module(cookie).

Cookie here might be also something like a dentry, which can be positive
or negative, and has some of the reference counting and locking semantics
we need for modules anyway.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

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



This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:30 EST