svn commit: r345171 - head/usr.sbin/bhyve

Fri Mar 15 16:22:18 UTC 2019

Em sáb, 16 de mar de 2019 às 00:03, Rodney W. Grimes <
freebsd at gndrsh.dnsmgr.net> escreveu:

> > Em sex, 15 de mar de 2019 ?s 22:12, Ian Lepore <ian at freebsd.org>
> escreveu:
> >
> > > 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 a new entry on MAINTAINERS:
> > https://svnweb.freebsd.org/base?view=revision&revision=344631
> >
> >
> > >
> > > 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.
> > >
> >
> > +1
> >
> > I got so frustrated with it recently that I have decided to don't
> > contribute with bhyve anymore, perhaps even with FreeBSD.
> > I still have some people under mentorship that I intend to finish and
> then
> > probably I will phase out.
>
> Your failure to get reviews, and infact even abandon one that had
> negative advice as to the validity of your suggested change and
> committing it anyway is more likely the cause here.
>
> You also committed code with no review at all that had to be reverted
> after the bugs it caused were found by an external down stream consumers
> of the bhyve code.
>
> You had code reverted by core due to a external attribution request,
> which had you been attending the bi monthly bhyve calls you would of
> known was an issue.
>
> I would suggest these are the reasons your feeling angry, and that
> I infact tried to reach out to jhb to discuss some of these earlier
> but that reach out was never returned.  I under stand your frustration,
> you are just wanting to do with best thing you can for the project
> and bhyve, can we try to find a better resolution to this situation
> than your exit?
>

>
> > > -- 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 */
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> > --
> >
> > --
> > Marcelo Araujo            (__)araujo at FreeBSD.org
> > \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
> > Power To Server.         .\. /_)
>
> --
> Rod Grimes
> rgrimes at freebsd.org
>

Sorry Rod, I don't want to be rude, but even though I'm not a native
English speaker, it hurts my eyes seeing the misspellings in your emails.
And I have spent enough time in public and private trying to talk with you,
I don't have this time anymore. So, I truly believe you should get the
maintainership of bhyve as it seems you are the most capable person to do
so. Wait, your previous mentor... well, I won't repeat his words!

Good lucky with bhyve, as a suggestion, one feature that at least myself
need is the capability to parse a configuration file and boot a guest vm.
That would be amazing!

Another feature that I want and I think the most important is: let people
get involved and evolve bhyve code.

Best,

-- 

-- 
Marcelo Araujo            (__)araujo at FreeBSD.org
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
Power To Server.         .\. /_)