From owner-svn-src-all@freebsd.org Thu Nov 5 19:21:37 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10A8AA26BE0; Thu, 5 Nov 2015 19:21:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5A611C6F; Thu, 5 Nov 2015 19:21:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igdg1 with SMTP id g1so19526165igd.1; Thu, 05 Nov 2015 11:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NtjwE4R/N3mDw+zsylkHQdyTLZ0uQu8UhsoxC6YIbjo=; b=m0LlBPQPyNHXy4YsxX7FYTXYF6xiF0zvH2o7t9Hg+ePXk1S0QnqTjcGGehUSE3aB6u LFpjmqQ8A5vZmCC0E2rvodie7LpcReUU8aUZxifiEPjqQxnFad3nNeaQNdJLs8kyUpfr 764PbXE4cGCMW0etnQOV4U+YN23trq2TPQ/YOzhp5vIRYdaFWJrVpXMTAWvZjxQJMlxb x+eM+nqhRK5pNmq1BIrzHey2JXzdKwwjFEkoAAEokESRfxwU0lMr51IYoDAduXSPfl4q wZed6PWUu86Y0tPBRJn1pJVh2zG2qsXPr9u5I7kvQtXbV19GsuzMSpi8mYcGpebpGtMJ sXMQ== MIME-Version: 1.0 X-Received: by 10.50.155.41 with SMTP id vt9mr4914985igb.22.1446751296161; Thu, 05 Nov 2015 11:21:36 -0800 (PST) Received: by 10.36.217.196 with HTTP; Thu, 5 Nov 2015 11:21:36 -0800 (PST) In-Reply-To: <4544430.IVoCLBVNIY@ralph.baldwin.cx> References: <201511012217.tA1MHdMJ047219@repo.freebsd.org> <20151102093603.0aebe7a8@bender.Home> <4544430.IVoCLBVNIY@ralph.baldwin.cx> Date: Thu, 5 Nov 2015 11:21:36 -0800 Message-ID: Subject: Re: svn commit: r290245 - in head/sys/contrib/vchiq/interface: vchi vchiq_arm From: Adrian Chadd To: John Baldwin Cc: Oleksandr Tymoshenko , Andrew Turner , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 19:21:37 -0000 On 5 November 2015 at 10:49, John Baldwin wrote: > On Monday, November 02, 2015 11:37:38 AM Oleksandr Tymoshenko wrote: >> >> > On Nov 2, 2015, at 1:36 AM, Andrew Turner wrote: >> > >> > On Sun, 1 Nov 2015 22:17:39 +0000 (UTC) >> > Oleksandr Tymoshenko wrote: >> > >> >> Author: gonzo >> >> Date: Sun Nov 1 22:17:39 2015 >> >> New Revision: 290245 >> >> URL: https://svnweb.freebsd.org/changeset/base/290245 >> >> >> >> Log: >> >> Synchronize with latest upstream VCHI code: >> >> >> >> - Add LIB_VERSION ioctl >> >> - Add CLOSE_DELIVERED ioctl >> >> - Bump code version >> >> >> >> Upstream version: 3782f2ad42c08f4d32f64138f8be7341afc380f5 >> > >> > Was there a reason we don't use the vendor-sys area for vchiq? >> >> What Adrian said: original code is not very portable and I have to go through manual merge in my staging repo and only then merge to sys/ area > > One benefit of keeping a corresponding area in vendor-sys in sync is it > makes it easier for other folks to pick this up in the future if need be. > > Noting the upstream version in each update is probably equivalent in > functionality, though it is not how we do it in the rest of the tree. > > Also, Adrian, most of us do a lot of this work (FreeBSD) as volunteers. Even > if some of us work on some of it for ${WORK} we work on other bits in our > spare time for $0 as well, so that's a lame cop out. Part of the reason we > do this in our spare time is because it's a chance to do things "right", not > just quick hacks to satisfy a business-deadline at ${WORK} (to paraphrase > gibbs@). Sure, but that's a case by case basis. This is definitely not the only example of code which we don't maintain as vendor imports because of the sheer amount of changes being done. At some point gonzo@, I or someone may end up taking the videocore stuff and re-porting with to minimize diffs. Same as the dri code - it's not in vendor. Same as (IIRC) the scsi drivers; same as the intel ethernet drivers, etc, etc. The vendor stuff seems to work fine with userland code that requires minimal changes. I'd love for that to change, but porting linux code doesn't always give us that opportunity. :) -adrian