[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120302163716.GA18758@joana>
Date: Fri, 2 Mar 2012 13:37:16 -0300
From: Gustavo Padovan <padovan@...fusion.mobi>
To: David Miller <davem@...emloft.net>
Cc: gustavo@...ovan.org, johan.hedberg@...il.com,
linville@...driver.com, netdev@...r.kernel.org
Subject: Re: pull request: bluetooth-next 2012-03-01
Hi Dave,
* David Miller <davem@...emloft.net> [2012-03-01 22:26:04 -0500]:
> From: David Miller <davem@...emloft.net>
> Date: Thu, 01 Mar 2012 22:23:16 -0500 (EST)
>
> > From: David Miller <davem@...emloft.net>
> > Date: Thu, 01 Mar 2012 22:16:43 -0500 (EST)
> >
> >> This was only three commits into your tree, therefore I'm not very
> >> optimistic to be honest with you.
> >
> > In the very next commit, 3175405b906a85ed2bad21e09c444266e4a05a8e we end
> > up with:
>
> And then 2 commits later in ff9ef5787046c3fd20cf9f7ca1cd70260c1eedb9:
>
> + if (hdev->discovery.state != DISCOVERY_STOPPED) {
> + err = cmd_status(sk, index, MGMT_OP_START_DISCOVERY,
> + MGMT_STATUS_BUSY);
> + goto failed;
> + }
>
> it must be isntead:
>
> err = cmd_status(sk, index, MGMT_OP_START_DISCOVERY,
> MGMT_STATUS_BUSY);
>
> And that's pretty much as far as I'm willing to go.
>
> You know what really pisses me off? This is the one issue I made a huge
> stink about last week, arguments to function calls and prototypes lining
> up properl. And it's in ever 2nd or 3rd commit in this pull request.
The styles in these patches is the same style we've been using in Bluetooth
code for more than 10 years and no one ever complained to us and we are the
only subsystem under Net doing something like this. I could find some examples
over the net code in a quick look.
I can see only two options here, leave this as is since this is coding style
we've been using since beginning or change the whole Bluetooth subsystem to
work like you said. In other words, are you telling me to make a patch to fix
this issue in the whole Bluetooth subsystem and not only in this pull request
diff? Otherwise we are putting the Bluetooth code in a inconsistent state with
two different coding styles. Is that what you want, an inconsistent state?
I'd be ok with changing the whole subsystem's style if you want.
Gustavo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists