linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Jon Loeliger <jdl@freescale.com>
Cc: linuxppc-dev@ozlabs.org, linuxppc64-dev@ozlabs.org
Subject: Re: PATCH powerpc Merge asm-ppc*/rwsem.h
Date: Fri, 23 Sep 2005 15:09:28 +0100	[thread overview]
Message-ID: <23115.1127484568@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <E1EIn23-0001pB-H0@jdl.com>


Jon Loeliger <jdl@freescale.com> wrote:

> No problem.  I _can_ resubmit the patch with this fix.
> However, I am not certain that I should yet.

I'd suggest that you wait until the merge is complete, I think.

> But what do you wan to do with ppc32 land then?
> Leaving it a "signed long" will limit ppc32 land but
> not ppc64 folks.  (No problem.)

I'd suggest "signed long" in both cases. A maximum of 32K processes on ppc32
is probably reasonable.

> Also, this begs the question of the comment from Paul:
> 
>     struct rw_semaphore {
> 	/* XXX this should be able to be an atomic_t  -- paulus */
> 	signed int		count;

Paul can be wrong sometimes:-)

Changing to atomic_t would leave the 32K process limit in place.

> Changing the size of counter will cause bad sizes
> due to the actual treatment of count as an atomic_t.

You will not be able to use the standard atomic ops unless you increase them
to 64-bits on ppc64.

> And if we _do_ convert it to be an atomic_t, should _that_
> be where the real type for count gets established?

You should not do that unless you increase atomic_t to 64-bits on ppc64.

> And finally, I've been working on merging header files
> under the vague guideline of "merge maintaining existing
> functionality/breakage".  I've been trying NOT to introduce
> simultaneous "improvements" at the risk of breaking something.

Sounds reasonable.

> To that end, I ask if the request to make 'count' be 64-bits
> should be submitted as a follow on patch that stands on its
> own and can clean up around it as necessary?  Or do you want
> it mixed in with this "merge" patch too?

Follow-on is fine.

David

  parent reply	other threads:[~2005-09-23 14:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-22 19:55 PATCH powerpc Merge asm-ppc*/rwsem.h Jon Loeliger
2005-09-23  7:32 ` David Howells
2005-09-23  7:44   ` Anton Blanchard
2005-09-23  7:52   ` David Howells
2005-09-23 12:52   ` Jon Loeliger
2005-09-23 14:09   ` David Howells [this message]
2005-09-24  0:46   ` Paul Mackerras
2005-09-26 11:38   ` David Howells

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=23115.1127484568@warthog.cambridge.redhat.com \
    --to=dhowells@redhat.com \
    --cc=jdl@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=linuxppc64-dev@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).