Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Mar 2019 07:55:49 -0600
From:      Ian Lepore <ian@freebsd.org>
To:        rgrimes@freebsd.org, Chuck Tuffli <chuck@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r345171 - head/usr.sbin/bhyve
Message-ID:  <7e312cdad08139c567cd43207191c97303831e9d.camel@freebsd.org>
In-Reply-To: <201903150231.x2F2VnR6027995@gndrsh.dnsmgr.net>
References:  <201903150231.x2F2VnR6027995@gndrsh.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2019-03-14 at 19:31 -0700, Rodney W. Grimes wrote:
> > Author: chuck
> > Date: Fri Mar 15 02:11:28 2019
> > New Revision: 345171
> > URL: https://svnweb.freebsd.org/changeset/base/345171
> > 
> > Log:
> >   Fix bhyve PCIe capability emulation
> >   
> >   PCIe devices starting with version 1.1 must set the Role-Based
> > Error
> >   Reporting bit.
> >   
> >   And while we're in the neighborhood, generalize the code
> > assigning the
> >   device type.
> >   
> >   Reviewed by:	imp, araujo, rgrimes
> >   Approved by:	imp (mentor)
> >   MFC after:	1 week
> >   Differential Revision: https://reviews.freebsd.org/D19580
> 
> This code requires maintainer approval before a commit,
> though this was well reviewed that doesnt exclude it
> from the MAINTAINERS entry.
> 

Where exactly does it say that in MAINTAINERS?  As another victim of
this sort of drive-by lynching after making a trivial bhyve change I
pretty seriously object to a vague and meaningless entry in MAINTAINERS
being used to pounce on anyone who dares to touch the precious bhyve
code.

There is no mention of bhyve in MAINTAINERS, for usr.sbin or elsewhere.
There is an entry for vmm(4), which to me does not say anything about
bhyve, yet somehow everybody is supposed to know what it means and
what-all territory it covers?

IMO, this sort of hyper-proprietary pouncing on everyone who dares
change a single line of code is not productive.  It is HIGHLY de-
motivating.  Large sweeping design changes are one thing, but pouncing
on every tiny minor commit is just not helpful.

-- Ian

> Leave it for now, I am sure jhb or thyco are fine with it,
> this is just a heads up FYI for future commits.
> 
> Bhyve code has been and still is under a fairly tight
> MAINTAINER status.
> 
> > Modified:
> >   head/usr.sbin/bhyve/pci_emul.c
> > 
> > Modified: head/usr.sbin/bhyve/pci_emul.c
> > ===================================================================
> > ===========
> > --- head/usr.sbin/bhyve/pci_emul.c	Fri Mar 15 02:11:27 2019	(r3
> > 45170)
> > +++ head/usr.sbin/bhyve/pci_emul.c	Fri Mar 15 02:11:28 2019	(r3
> > 45171)
> > @@ -953,7 +953,10 @@ pci_emul_add_pciecap(struct pci_devinst *pi,
> > int type)
> >  	bzero(&pciecap, sizeof(pciecap));
> >  
> >  	pciecap.capid = PCIY_EXPRESS;
> > -	pciecap.pcie_capabilities = PCIECAP_VERSION |
> > PCIEM_TYPE_ROOT_PORT;
> > +	pciecap.pcie_capabilities = PCIECAP_VERSION | type;
> > +	/* Devices starting with version 1.1 must set the RBER bit */
> > +	if (PCIECAP_VERSION >= 1)
> > +		pciecap.dev_capabilities = PCIEM_CAP_ROLE_ERR_RPT;
> >  	pciecap.link_capabilities = 0x411;	/* gen1, x1 */
> >  	pciecap.link_status = 0x11;		/* gen1, x1 */
> >  
> > 
> > 
> 
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7e312cdad08139c567cd43207191c97303831e9d.camel>