public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Zhao Yakui <yakui.zhao@intel.com>,
	Daniel Walker <dwalker@mvista.com>,
	linux-acpi@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	len.brown@intel.com
Subject: Re: [PATCH 1/3] acpi: add real mutex function calls
Date: Mon, 21 Jul 2008 21:15:47 +0200	[thread overview]
Message-ID: <4884E063.8080908@linux.intel.com> (raw)
In-Reply-To: <1216632297.7257.31.camel@twins>

Peter Zijlstra wrote:
> On Mon, 2008-07-21 at 11:17 +0200, Andi Kleen wrote:
>> Peter Zijlstra wrote:
>>> On Mon, 2008-07-21 at 09:51 +0800, Zhao Yakui wrote:
>>>> On Sat, 2008-07-19 at 11:16 -0700, Daniel Walker wrote:
>>>>> Instead of re-using semaphores for the mutex operation, I've
>>>>> added usage of the kernel mutex for the os mutex implementation.
>>>>>
>>>> What is the advantage that the kernel mutex is used for the ACPI mutex
>>>> implementation instead of using semaphore?
>>>> And it seems that too much ACPICA source code is touched.
>>> You get help from lockdep, and also our goal is to fully eradicate
>>> semaphore usage.
>> Issue is that ACPICA is shared with other OS source code and to replace 
>> a major interface like this would mean replacing it for everyone. It 
>> might end up with ACPICA just reimplementing a semaphore like wrapper if 
>> semaphores really go away, but I don't really see that coming anyways.
> 
> Andi, you know better than that.

Know better than what?

My understanding was that there are a few areas
in the kernel who really use true semaphore semantics and I don't see it 
as particularly useful to force them to use something else that doesn't 
fit them as well.  And there are areas like ACPICA where semaphores are 
an useful abstraction because of other consideration (in ACPICA's case 
due to portability).

Especially now that semaphores are not duplicated per architecture 
anymore so actually keeping them around is not that costly. Yes they are 
incompatible to lockdep, but lockdep support is only one consideration 
among others and not the master of all code.

Especially adding own semaphore wrappers to some code like ACPICA
when there are already perfectly usable generic semaphores wouldn't
strike me as an improvement and that ugliness of that would IMHO far 
outweight the benefit of lockdep support.

-Andi


  reply	other threads:[~2008-07-21 19:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-19 18:16 [PATCH 0/3] acpi: acpi: sem out, mutex/completion in Daniel Walker
2008-07-19 18:16 ` [PATCH 1/3] acpi: add real mutex function calls Daniel Walker
2008-07-19 18:16   ` [PATCH 2/3] acpi: semaphore removal Daniel Walker
2008-07-19 18:16     ` [PATCH 3/3] Add lockdep integration for the ACPI mutex usage Daniel Walker
2008-07-20  8:15     ` [PATCH 2/3] acpi: semaphore removal Dave Chinner
2008-07-20 14:49       ` Daniel Walker
2008-07-21  1:51   ` [PATCH 1/3] acpi: add real mutex function calls Zhao Yakui
2008-07-21  9:14     ` Peter Zijlstra
2008-07-21  9:17       ` Andi Kleen
2008-07-21  9:24         ` Peter Zijlstra
2008-07-21 19:15           ` Andi Kleen [this message]
2008-07-21 19:33             ` Peter Zijlstra
2008-07-21 19:55               ` Matthew Wilcox
2008-07-21 20:22                 ` Daniel Walker
2008-07-21 20:00               ` Andi Kleen
2008-07-21 20:38                 ` Daniel Walker
2008-07-21 13:59         ` Daniel Walker
2008-07-21 13:56     ` Daniel Walker
2008-07-21 19:20       ` Andi Kleen
2008-07-21 19:39         ` Daniel Walker
2008-07-23 22:14           ` Moore, Robert
2008-07-24 12:44             ` Daniel Walker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4884E063.8080908@linux.intel.com \
    --to=ak@linux.intel.com \
    --cc=dwalker@mvista.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=yakui.zhao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox