lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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