All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH 2/4] SGI Altix cross partition functionality (1st revision)
Date: Sat, 04 Sep 2004 11:12:57 +0000	[thread overview]
Message-ID: <20040904121257.D14123@infradead.org> (raw)
In-Reply-To: <20040616163514.GB27891@sgi.com>

> > Why do you have three different option when the only way they're usefull
> > is to have all three enabled at the same time.
> 
> By this I asssume you mean that rather than having both IA64_SGI_SN_XPC
> and IA64_SGI_SN_XPNET, we should have just one, like IA64_SGI_SN_XP, that
> causes all the parts to get built. Correct?

Yes.

> > > +	case xpcMsgReceived:		return "xpcMsgReceived";
> > > +	case xpcMsgDelivered:		return "xpcMsgDelivered";
> > 
> > Please don't add strerror-lookalikes to the kernel.
> 
> I'm not clear on this. Do you mean ditch xpc_get_ascii_reason_code()
> altogether and have no mapping of a numeric reason code to an ASCII
> string?

Yes.  strerror() is entirely userspace policy.

> > A single mutex wouldn't do it?  It doesn't exactly look like it's used in
> > fast-paths
> 
> Yeah, you're right it's not a fast-path and a single mutex would work.
> I kind of like putting the lock within the data structure it's protecting.
> When you get the lock, you've already got the data of interest in your
> cache (obviously this depends on the size of the structure and where in
> the structure the data you're interested in resides). We're not talking
> about very much memory lost because of this. (The way it is we only end
> up with a total of two semaphores, instead of just one.)

Well, Linux is difficult.  First rule of thumb is keep it simple, and
if you ever need a fastpath semaphore you're better of making it a separate
entinity from the registration sempahore.


  parent reply	other threads:[~2004-09-04 11:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-16 16:35 [PATCH 2/4] SGI Altix cross partition functionality Dean Nelson
2004-06-16 17:28 ` Christoph Hellwig
2004-06-16 20:22 ` Keith Owens
2004-07-29 18:36 ` Dean Nelson
2004-08-31 19:22 ` [PATCH 2/4] SGI Altix cross partition functionality (1st revision) Dean Nelson
2004-09-01 10:19 ` Robin Holt
2004-09-04 11:12 ` Christoph Hellwig [this message]
2004-09-04 11:15 ` Christoph Hellwig
2004-09-04 16:35 ` Russ Anderson
2004-09-04 16:55 ` Christoph Hellwig
2004-09-04 16:57 ` Christoph Hellwig
2004-09-05 11:45 ` Robin Holt
2004-12-20 18:45 ` Dean Nelson
2004-12-21 12:20 ` Dean Nelson
2005-01-05 11:35 ` Christoph Hellwig
2005-01-05 11:35 ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2004-08-24 18:00 [PATCH 0/4] SGI Altix cross partition functionality (1st Dean Nelson
2004-08-24 18:23 ` [PATCH 2/4] SGI Altix cross partition functionality (1st revision) Dean Nelson
2004-08-24 19:17   ` Christoph Hellwig

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=20040904121257.D14123@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-ia64@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.