Date: Fri, 15 Mar 2019 09:41:01 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: araujo@freebsd.org Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, Ian Lepore <ian@freebsd.org>, Chuck Tuffli <chuck@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r345171 - head/usr.sbin/bhyve Message-ID: <201903151641.x2FGf19e031000@gndrsh.dnsmgr.net> In-Reply-To: <CAOfEmZgZUUhxtdB58kUovyVbYVKv5qx5rvMKRz4PLOP9SjK4aA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Em s?b, 16 de mar de 2019 ?s 00:03, Rodney W. Grimes < > freebsd@gndrsh.dnsmgr.net> escreveu: > > > > Em sex, 15 de mar de 2019 ?s 22:12, Ian Lepore <ian@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@FreeBSD.org > > > \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>; \/ \ ^ > > > Power To Server. .\. /_) > > > > -- > > Rod Grimes > > rgrimes@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. I need to bring back ispell, your right, I am a horrid speller, and your also right, that does make it very hard for a non native speaker to read my email some times. > 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! I do not want or desire in any way to be the maintainer of bhyve, infact when Peter Grehan suggested I make myself maintaner over the vmrun.sh script after I cleaned it up, I replied, no thanks. > 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! I believe there are 2 or 3 port implementations of this, and the developement group, as you are well aware, has spoken about this very issue several times. Much of that was being driven by you, with input from the group. > Another feature that I want and I think the most important is: let people > get involved and evolve bhyve code. Who is stopping anyone from becoming involved? The only stopping I see occuring with respect to you directly, is buggy code getting in the tree. I am sorry that you can not seem to understand the feedback in reviews is nothing personal in anyway, and that people are addressing bugs in the code and giving ressons that it should be changed. You take issue with that feedback and it seems to take an effort to convince you that your code is wrong and needs changed. And that is not only my feedback that you have ignored, that appears to be the case with most feedback. I am/was actively working with Patrick Mooney of Joyent to bring back there changes to FreeBSD, and to make sure changes I was working on can transparently port to Illumos. There is now mutual co-operation between the 2 projects, jhb and myself have both been asked to took at Joyent changes in review and give feedback there, and Patrick is activley participating in the FreeBSD phabricator reviews. I have enumerated all phab reviews I could find and enumerated those in the meeting so that we can discuss them and poll the respective parties to try and get that code moved forward, in that process I have gotten atleast one more person involved in my work on removing the constant VM_MAXCPUS and attributed him with a very early version of the patch. > Marcelo Araujo (__)araujo@FreeBSD.org -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201903151641.x2FGf19e031000>