From: "David S. Miller" <davem@redhat.com>
To: alan@lxorguk.ukuu.org.uk
Cc: rml@tech9.net, torvalds@transmeta.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
riel@conectiva.com.br, wli@holomorphy.com
Subject: Re: [PATCH] generalized spin_lock_bit
Date: Sat, 20 Jul 2002 18:31:33 -0700 (PDT) [thread overview]
Message-ID: <20020720.183133.67807986.davem@redhat.com> (raw)
In-Reply-To: <1027211185.17234.48.camel@irongate.swansea.linux.org.uk>
Secondly many platforms want to implement their locks in other ways.
Atomic bitops are an x86 luxury so your proposal simply generates
hideously inefficient code compared to arch specific sanity
For an asm-generic/bitlock.h implementation it is more than
fine. That way we get asm-i386/bitlock.h that does whatever
it wants to do and the rest of asm-*/bitlock.h includes
the generic version until the arch maintainer sees fit to
do otherwise.
See the difference between what we have here now? It means all ports
will at least sort-of work when the change gets installed. A lot of
testing gets lost because ports break on a daily basis due to changes
when done like this.
Look at the asm/rmap.h stuff, that was done right and platforms kept
at least compiling when that change went in.
I don't mind architecture breakage when truly necessary to change
stuff, but when it can be avoided reasonably it should.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2002-07-21 1:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-20 20:21 Robert Love
2002-07-20 20:40 ` Linus Torvalds
2002-07-20 21:15 ` William Lee Irwin III
2002-07-20 21:19 ` Robert Love
2002-07-20 21:20 ` Robert Love
2002-07-20 23:25 ` Linus Torvalds
2002-07-20 22:27 ` David S. Miller
2002-07-20 22:46 ` Robert Love
2002-07-21 0:26 ` Alan Cox
2002-07-21 1:31 ` David S. Miller [this message]
2002-07-21 13:48 ` Alan Cox
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=20020720.183133.67807986.davem@redhat.com \
--to=davem@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
--cc=rml@tech9.net \
--cc=torvalds@transmeta.com \
--cc=wli@holomorphy.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