Re: [PATCH v2] x86: Add a list for custom page fault handlers.

[Arjan van de Ven]

On Thu, 31 Jan 2008 18:02:53 +0200
Pekka Paalanen <pq@xxxxxx> wrote:

> > could you please send us a patch for the whole mmiotrace
> > kernel-side feature, so that we can have a look at the general
> > structure of this? (and the interaction with change_page_attr(),
> > etc.) Even if it's not functional (and wont even build/boot) at the
> > moment. Thanks,
> 
> Very well, first the revised custom page fault handler patch.
> Changes since the previous submit:
> - use spin_lock_irqsave instead of spin_lock
> - Harvey Harrison's clean-up with the #ifdefs
> - handler call site moved earlier
> - remove sync RCU call
> 
> I'm not aware of any functional problems with this one.
> 
> Arjan, you said you don't like this. May I ask why?

it's overhead that's rarely used, and worse, it suffers from the LSM disease:
it's a hook without visibility into the callers. Esp if there's only 1 user, a direct call
is not only faster, it also shows you what is going on when you're reading the code.
THe page fault stuff is tricky enough as it is without any "call arbitrary thing" hooks into
it

> This is most convinient for mmiotrace as it is meant to be a module.

that's not per se mutually exclusive, there's other cases like this already
(but even then, I don't want to go through hoops to make mmiotracing a module;
for me I can totally see it becoming a full mature member of the kernel, and if
that means a few things have to be changed in the normal kernel, or infrastructure
added, I'm totally ok with that)

> I'm also using this as an excuse to let other people to get into the
> page fault handler with their out-of-tree-today modules.

this is exactly the point.. it becomes a totally opaque thing, a random hook.


-- 
If you want to reach me at my work email, use arjan@xxxxxxxxxxxxxxx
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/