From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Stl9D-0001sw-CZ for qemu-devel@nongnu.org; Tue, 24 Jul 2012 15:52:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Stl9C-0001mt-9w for qemu-devel@nongnu.org; Tue, 24 Jul 2012 15:51:59 -0400 Received: from mail-gh0-f173.google.com ([209.85.160.173]:50368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Stl9C-0001ml-54 for qemu-devel@nongnu.org; Tue, 24 Jul 2012 15:51:58 -0400 Received: by ghrr14 with SMTP id r14so7186685ghr.4 for ; Tue, 24 Jul 2012 12:51:57 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87sjcho6g8.fsf@blackfin.pond.sub.org> References: <0e5d35008c438b250c66b1ab4e774bd718521d8c.1342269249.git.blauwirbel@gmail.com> <87boje1s47.fsf@blackfin.pond.sub.org> <87sjcho6g8.fsf@blackfin.pond.sub.org> From: Blue Swirl Date: Tue, 24 Jul 2012 19:51:36 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v3 2/2] bitops: fix types List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Peter Maydell , qemu-devel@nongnu.org On Tue, Jul 24, 2012 at 9:26 AM, Markus Armbruster wrote: > Peter Maydell writes: > >> On 23 July 2012 18:33, Blue Swirl wrote: >>> I'm getting a strong feeling that it's a bad idea to reuse any Linux >>> kernel sources since they are seen as divine and untouchable, unlike >>> for example BSD queue macros. > > Reusing good code that solves the problem at hand can be a bad idea if > you can't resist the temptation to tinker with it, yet can't be bothered > to upstream your improvements. Then you might as well build your own > bikeshed from scratch :) There's nothing wrong in tinkering with reused good code. As I explained, there's little point to upstream these changes, so 'not bothering' is false accusation. > >> We should also try to avoid deviations in our queue macros, > > Agree. Avoiding "deviations" can be secondary to many other needs. > >> and I think we do (eg commit 6095aa8 added functionality by >> moving us closer into sync with the BSD macros rather than >> by reinventing the wheel which was IIRC what the initial pre-code-review >> patch did).