svn commit: r290245 - in head/sys/contrib/vchiq/interface: vchi vchiq_arm

[Adrian Chadd]

On 5 November 2015 at 10:49, John Baldwin <jhb at freebsd.org> wrote:
> On Monday, November 02, 2015 11:37:38 AM Oleksandr Tymoshenko wrote:
>>
>> > On Nov 2, 2015, at 1:36 AM, Andrew Turner <andrew at fubar.geek.nz> wrote:
>> >
>> > On Sun, 1 Nov 2015 22:17:39 +0000 (UTC)
>> > Oleksandr Tymoshenko <gonzo at FreeBSD.org> 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