| Message ID | f7eb26ad-39be-2918-627b-5f4981d07808@users.sourceforge.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> For starters make sure the patches land actually on the list. How do you think about to take another look at this update suggestion also by the usual archive interfaces? * https://patchwork.kernel.org/patch/9344521/ * https://lkml.kernel.org/r/<f7eb26ad-39be-2918-627b-5f4981d07808@users.sourceforge.net> > Only the cover letter arrived here. Would you like to clarify any more technical difficulties around the desired message exchange? Regards, Markus
On Thu, Sep 22, 2016 at 03:11:25PM +0200, SF Markus Elfring wrote: > > If you restricted yourself to fixing bugs only then you would maybe fix more > > bugs than you introduce but as it you are making the kernel worse. > > Would you like to discuss the statistics for my failure (or success) rate > a bit more so that involved issues can be clarified in a constructive way? It should be that you target 20 bug fixes for each new regression that you add. Since you are just sending clean ups, every bug you introduce sets us further and further back. There is no hope for improving the kernel because you are not even trying to fix 20 bugs, only introducing them. Once you fix 20 bugs, then you will be even and you can start sending cleanups again. This is fair. regards, dan carpenter
On Do, 2016-09-22 at 19:16 +0200, SF Markus Elfring wrote: > > For starters make sure the patches land actually on the list. > > How do you think about to take another look at this update suggestion > also by the usual archive interfaces? > > * https://patchwork.kernel.org/patch/9344521/ > > * https://lkml.kernel.org/r/<f7eb26ad-39be-2918-627b-5f4981d07808@users.sourceforge.net> I fail to see the point in this change. On init failure qdev will be released anyway, and whenever the fields are initialized or not when kfree() is called doesn't matter at all. > > Only the cover letter arrived here. > > Would you like to clarify any more technical difficulties around > the desired message exchange? Hmm, not sure what happened. According to the kernel.org link the patch has been sent to dri-devel (where I'm subscribed), but the patch never landed in by mailbox for some reason. cheers, Gerd
On Thu, Sep 22, 2016 at 1:24 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote: > On Thu, Sep 22, 2016 at 03:11:25PM +0200, SF Markus Elfring wrote: >> > If you restricted yourself to fixing bugs only then you would maybe fix more >> > bugs than you introduce but as it you are making the kernel worse. >> >> Would you like to discuss the statistics for my failure (or success) rate >> a bit more so that involved issues can be clarified in a constructive way? > > It should be that you target 20 bug fixes for each new regression that > you add. > > Since you are just sending clean ups, every bug you introduce sets us > further and further back. There is no hope for improving the kernel > because you are not even trying to fix 20 bugs, only introducing them. > > Once you fix 20 bugs, then you will be even and you can start sending > cleanups again. This is fair. > At the risk of piling on, but hopefully to benefit Markus going forward: I will refrain from merging any more style/checkpatch/"code cleanup" patches from Markus until we start getting real, tested, bug fixes. Sean > regards, > dan carpenter > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 23 September 2016 at 17:25, Sean Paul <seanpaul@chromium.org> wrote: > On Thu, Sep 22, 2016 at 1:24 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote: >> On Thu, Sep 22, 2016 at 03:11:25PM +0200, SF Markus Elfring wrote: >>> > If you restricted yourself to fixing bugs only then you would maybe fix more >>> > bugs than you introduce but as it you are making the kernel worse. >>> >>> Would you like to discuss the statistics for my failure (or success) rate >>> a bit more so that involved issues can be clarified in a constructive way? >> >> It should be that you target 20 bug fixes for each new regression that >> you add. >> >> Since you are just sending clean ups, every bug you introduce sets us >> further and further back. There is no hope for improving the kernel >> because you are not even trying to fix 20 bugs, only introducing them. >> >> Once you fix 20 bugs, then you will be even and you can start sending >> cleanups again. This is fair. >> > > At the risk of piling on, but hopefully to benefit Markus going forward: > > I will refrain from merging any more style/checkpatch/"code cleanup" > patches from Markus until we start getting real, tested, bug fixes. I'd prefer if everyone on dri-devel just ignored Markus at this stage, If you are going to pick up his patches, please spend time making sure they are correct and tested, as he doesn't seem to. Markus, please contact the list in advance in future before posting a bunch of patches that don't fix any problems. Dave.
>> Would you like to discuss the statistics for my failure (or success) rate >> a bit more so that involved issues can be clarified in a constructive way? > > It should be that you target 20 bug fixes for each new regression > that you add. How do you think about to clarify any concrete "regression" a bit more? > There is no hope for improving the kernel I have got an other impression. - I am trying to help also for this goal. > because you are not even trying to fix 20 bugs, Under which circumstances would you dare to acknowledge once more that I improved anything for which you care about? > only introducing them. It's a pity that you interpret some of my contributions in this way. > Once you fix 20 bugs, then you will be even and you can start sending > cleanups again. This is fair. How much will the suggested software refactorings influence the kind of error counter that you prefer so far? Regards, Markus
> I will refrain from merging any more style/checkpatch/"code cleanup" > patches from Markus until we start getting real, tested, bug fixes. Can such a kind of feedback be also interpreted in the way that you insist to keep some weaknesses which I tried to point in the Linux source code out for another while? How do you think about to clarify your ranking for various update candidates in this software? Regards, Markus
> Markus, please contact the list in advance in future before posting a bunch > of patches that don't fix any problems. I am trying to improve various open issues also in Linux source files. Unfortunately, some of the proposed changes might not fit to your software development attention at the moment. How are the chances that corresponding change acceptance will evolve a bit more after a while? Regards, Markus
On 23 September 2016 at 09:50, SF Markus Elfring <elfring@users.sourceforge.net> wrote: >> Markus, please contact the list in advance in future before posting a bunch >> of patches that don't fix any problems. > > I am trying to improve various open issues also in Linux source files. > That the fact that you see issues (in these particular cases) while others do not indicates that the commit summary could be explained better. A good commit summary should provide enough information to do that and make people _want_ the patch. From my limited experience through your patches (just skimmed a few) you seems to be describing what the patch does as opposed to why it does it and why should one find it interesting/wanted. You might want to read through the following [1] [2] and many others that exist out there. -Emil [1] http://chris.beams.io/posts/git-commit/ [2] http://who-t.blogspot.fi/2009/12/on-commit-messages.html
>> I am trying to improve various open issues also in Linux source files. >> > That the fact that you see issues (in these particular cases) while > others do not I guess that the discussed "story" affects more challenges in communication and different opinions about where to invest software development attention. > indicates that the commit summary could be explained better. I imagine that there are a few improvement possibilities left over. > A good commit summary should provide enough information to do that This advice is generally fine. > and make people _want_ the patch. I guess that this expectation can become a research topic for some knowledge fields, can't it? There are update suggestion where the probability for acceptance is higher than for others. Some maintainers have got their own difficulties with changes when they categorise them as "ordinary clean-up". > From my limited experience through your patches (just skimmed a few) Thanks for your general interest. > you seems to be describing what the patch does My collection of update suggestions is evolving over some source code search patterns. I find that this approach fits to the recommended imperative wording style according to document "SubmittingPatches", doesn't it? I dared also some deviations or variations already. > as opposed to why it does it and why should one find it interesting/wanted. I am trying to express also this information to some degree. Regards, Markus
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c index 76852f1..76780c2 100644 --- a/drivers/gpu/drm/qxl/qxl_kms.c +++ b/drivers/gpu/drm/qxl/qxl_kms.c @@ -212,10 +212,6 @@ static int qxl_device_init(struct qxl_device *qdev, /* TODO - slot initialization should happen on reset. where is our * reset handler? */ qdev->n_mem_slots = qdev->rom->slots_end; - qdev->slot_gen_bits = qdev->rom->slot_gen_bits; - qdev->slot_id_bits = qdev->rom->slot_id_bits; - qdev->va_slot_mask = - (~(uint64_t)0) >> (qdev->slot_id_bits + qdev->slot_gen_bits); qdev->mem_slots = kmalloc_array(qdev->n_mem_slots, sizeof(*qdev->mem_slots), GFP_KERNEL); @@ -260,7 +256,10 @@ static int qxl_device_init(struct qxl_device *qdev, INIT_WORK(&qdev->gc_work, qxl_gc_work); - + qdev->slot_gen_bits = qdev->rom->slot_gen_bits; + qdev->slot_id_bits = qdev->rom->slot_id_bits; + qdev->va_slot_mask = + (~(uint64_t)0) >> (qdev->slot_id_bits + qdev->slot_gen_bits); return 0; }