All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: kernel-janitors@vger.kernel.org
Subject: Re: [KJ] [PATCH] unified spinlock
Date: Thu, 20 Jan 2005 15:44:24 +0000	[thread overview]
Message-ID: <41EFD1D8.7090305@osdl.org> (raw)
In-Reply-To: <41EFCFDC.4060509@osdl.org>

Matthew Wilcox wrote:
> On Thu, Jan 20, 2005 at 07:35:56AM -0800, Randy.Dunlap wrote:
> 
>>Matthew Wilcox wrote:
>>
>>>On Thu, Jan 20, 2005 at 08:56:18PM +0530, Amit Gud wrote:
>>>
>>>
>>>>Unify the spinlock initialization as far as possible.
>>>
>>>
>>>Why would you want to replace a statically initialised spinlock with
>>>one that's initialised at runtime?
>>
>>I wondered that also, since I prefer the compile-time inits myself.
>>so I looked at the KJ TODO list
>><http://janitor.kernelnewbies.org/TODO> and it says:
>>
>>From: Jonathan Corbet
>>
>>Unified spinlock initialization:
>>convert all explicit lock initializations to spin_lock_init() or
>>rwlock_init().  (Besides consistency this also helps automatic lock
>>validators and debugging code.)
>>
>>http://lwn.net/Articles/109505/
>>http://linux.bkbits.net:8080/linux-2.6/cset@419a6f292wHnthuDzw7VfgECNLmvLg?nav=index.html|ChangeSet@-8w
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>I don't find the consistency part compelling at all.
>>If the change helps some static source analyzers, however, that would
>>be a good thing, but not a strong one (IMO).
> 
> 
> I think this is referring to initialisation of spinlocks that are
> allocated dynamically, not statically.  If a lock validator can't cope
> with that, it needs to be fixed, IMO.
> 
Having just looked at the LWN.net article, is this (still) true?

<quote>
The stated reasons for this change include consistency and making life 
easier for automatic lock validators. There is also an unstated, but 
evident reason: the assignment form of lock initialization gets in the 
way of the realtime preemption patches. Those patches change most 
spinlocks in the kernel to a different, mutex type, and that breaks 
the initializers. As a result, the preemption patches must change all 
of those initializations throughout the kernel. By putting those 
specific changes into the mainline, it is possible to make the 
realtime patches smaller, less intrusive, and a little bit less scary.
</quote>

-- 
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors

  reply	other threads:[~2005-01-20 15:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-20 15:35 [KJ] [PATCH] unified spinlock Randy.Dunlap
2005-01-20 15:44 ` Randy.Dunlap [this message]
2005-01-20 15:47 ` Matthew Wilcox
2005-01-20 16:50 ` Greg KH
2005-01-20 20:04 ` Matthew Wilcox
2005-01-20 20:09 ` Greg KH
2005-01-22 18:12 ` Domen Puncer

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=41EFD1D8.7090305@osdl.org \
    --to=rddunlap@osdl.org \
    --cc=kernel-janitors@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.