From: Mark Fasheh <mark.fasheh@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [patch 1/1] ocfs2-timeout-protocol.patch
Date: Thu Nov 30 09:37:41 2006 [thread overview]
Message-ID: <20061130173735.GQ30647@ca-server1.us.oracle.com> (raw)
In-Reply-To: <608ABF1E-301E-4CCA-9A2C-0C515FFFE03F@suse.de>
On Thu, Nov 30, 2006 at 01:24:29PM +0100, Andrew Beekhof wrote:
> >Can you not re-write the function prototypes unless they're actually
> >changing please? It clutters up the patch and makes it harder to
> >find the
> >actual code to check (see below).
>
> ah, bad habit i picked up working on smaller projects.
> is it ok in a separate patch? or have I got my wrap points set too
> small by default?
In general if you see something that's inconsisent with
Documentation/CodingStyle, then yeah fixing it in a seperate patch is fine.
As far as those functions are concerned, if you're not happy with the
indentation, then it would be nicest if you got them right in the patch
which introduced them.
> >>+ if (sc->sc_page_off == sizeof(struct o2net_handshake)) {
> >>+ o2net_check_handshake(sc);
> >>+ if(sc->sc_handshake_ok == 0) {
> >>+ BUG_ON(sizeof(struct o2net_handshake)
> >>+ == sizeof(struct o2net_msg));
> >Is this necessary?
>
> I wasnt sure at the time - see below - so i wanted to make sure it at
> least died sanely
> apparently i still needed education on how that is done :)
>
> >Didn't we fix the logic such that the relative sizes
> >don't matter any more? If it _is_ necessary, then it should be a
> >BUILD_BUG_ON() in a more visible place,
>
> ah, I was not familiar with that macro yet
Yeah, I'm mostly going on your description of the patch, and Zach's
description of the problem. I'll have to look more closely to see if this is
still something we need to trap or not.
> >with a nice fat comment explaining
> >why...
> >
> >>+ ret = -EPROTO;
> >>+ }
> >>+ goto out;
> >Do you mean to move that goto within the
> >
> >if (sc->sc_handshake_ok == 0) {
> >
> >block? I _think_ it's ok for us to continue otherwise...
>
> i did - but if we never want to process an o2net_msg if the handshake
> has not been completed, then i can structure things a little
> differently/clearly
Hmm, yeah... It looks like what'd happen if we don't get a properly sized
handshake is that we'd continue to process the o2net_msg, which I don't
think we want to do. If we skipped that, then we don't have to depend on the
sizes not matching... Which is fine because I don't think we ought to be
processing messages from nodes which haven't properly connected to us yet.
> I'll resubmit once we sort out the o2net_msg / o2net_handshake
> situation
Great, thanks alot Andrew!
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com
next prev parent reply other threads:[~2006-11-30 9:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-29 1:04 [Ocfs2-devel] [patch 0/1] OCFS Configurable timeouts - Revision 2 abeekhof
2006-11-29 1:04 ` [Ocfs2-devel] [patch 1/1] ocfs2-timeout-protocol.patch abeekhof
2006-11-29 15:30 ` Zach Brown
2006-11-29 15:31 ` Mark Fasheh
2006-11-30 4:25 ` Andrew Beekhof
2006-11-30 9:37 ` Mark Fasheh [this message]
2006-11-30 17:50 ` [Ocfs2-devel] [patch 0/1] OCFS Configurable timeouts - Revision 2 Joel Becker
2006-12-01 0:16 ` Andrew Beekhof
-- strict thread matches above, loose matches on Subject: below --
2006-11-21 7:12 abeekhof
2006-11-21 7:12 ` [Ocfs2-devel] [patch 1/1] ocfs2-timeout-protocol.patch abeekhof
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=20061130173735.GQ30647@ca-server1.us.oracle.com \
--to=mark.fasheh@oracle.com \
--cc=ocfs2-devel@oss.oracle.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 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.