From owner-freebsd-arch@FreeBSD.ORG Fri Mar 14 06:40:36 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 789501065671 for ; Fri, 14 Mar 2008 06:40:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 215C98FC1C for ; Fri, 14 Mar 2008 06:40:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m2E6b7u8084978; Fri, 14 Mar 2008 00:37:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 14 Mar 2008 00:37:49 -0600 (MDT) Message-Id: <20080314.003749.-432746071.imp@bsdimp.com> To: jroberson@chesapeake.net From: "M. Warner Losh" In-Reply-To: <20080313200839.S1091@desktop> References: <200803131516.12284.jhb@freebsd.org> <84dead720803132232k15c3aad7pe59875f0c84e0c27@mail.gmail.com> <20080313200839.S1091@desktop> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.ORG Subject: Re: [PATCH] hwpmc(4) changes to use 'mp_maxid' instead of 'mp_ncpus'. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2008 06:40:36 -0000 In message: <20080313200839.S1091@desktop> Jeff Roberson writes: : In general we accept vendor patches that are not disruptive even in the : case that the general communit doesn't perceive the real value. It is : important for us to work with and encourage vendors. ... : The rest of the generic code in the kernel already supports this. Juniper : claims to have tested and is using this feature. Furthermore, it will get : us a tiny step closer to being able to support pluggable cpus in a : virtualized environment. I'd like to echo these sentiments. We've generally been willing to accept code from vendors that makes their lives easier, even when that code doesn't directly benefit the project. We do this on the theory that if we make their life easy, they will contribute to the project. Juniper has certainly given a large chunk of code to the project (a fairly complete MIPS port that has been integrated with the so-called "mips2" port and will be headed into the tree soonish), which is certainly a lot more code than has been given from vendors whom we've made much bigger accommodations to. In this case a vendor came forward with a patch that introduces no real additional burdon to the volunteers who are maintaining the code. It seems like a no brainer to me to commit it. There's certainly no compelling technical argument against it. I work for Cisco. Cisco has no love for Juniper, and vice versa. However, I put that aside for the good of the project and work with people from Juniper all the time to make the project better by focusing on the technology. The project has similar expectations for all its developers: if there's a technical reason to not do something, then that's OK. If there's a political reason, especially one that isn't shared honestly an openly, then the bar is much much higher to exclude the technology from the tree. What would people think if I were to block the MIPS stuff from Juniper just because it came from Juniper and I work for a company that is in competition with Juniper? I don't think it would be too favorable. Warner