OK, I checked on the locking issue with Dong Wei and according to him, ESI is logically a part of SAL, so the same lock should be used to serialize SAL and ESI calls. In other words, the current patch should be fine. Thanks, --david On 6/15/06, David Mosberger-Tang <David.Mosberger@xxxxxxx> wrote:
Hi Tony, Below is a revised version of the ESI-support patch with the following changes: * Export ia64_esi_call and ia64_esi_call_phys() as GPL symbols. * Disallow building esi.c as a module for now. Building as a module would currently lead to an unresolved reference to "sal_lock" on SMP kernels because that symbol doesn't get exported. If it turns out that ESI calls can be locked separately from SAL calls, we can replace sal_lock with a new esi_lock and reenable building as a module (I'm checking into whether or not this is safe). * Export esi_call_phys() only if ESI is enabled. * Remove internal stuff from esi.h and add a "proc_type" argument to ia64_esi_call() such that serialization-requirements can be expressed (ESI follows SAL here, where procedure calls may have to be serialized, are MP-safe, or MP-safe andr reentrant). Signed-off-by: David Mosberger <David.Mosberger@xxxxxxx> --david -- Mosberger Consulting LLC, http://www.mosberger-consulting.com/
-- Mosberger Consulting LLC, http://www.mosberger-consulting.com/ - : send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|