linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: SF Markus Elfring <elfring@users.sourceforge.net>
To: Daniele Nicolodi <daniele@grinta.net>
Cc: linux-media@vger.kernel.org,
	Alexey Khoroshilov <khoroshilov@ispras.ru>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-janitors@vger.kernel.org
Subject: Re: Clarification for acceptance statistics?
Date: Mon, 12 Dec 2016 23:11:16 +0100	[thread overview]
Message-ID: <dc59427b-5631-b7e7-e9e9-80e786a8c2d6@users.sourceforge.net> (raw)
In-Reply-To: <a694926d-eedd-5d51-54d0-7ba88775c42e@grinta.net>

> The question was: have you ever had a patch changing code in the form
> 
> {
> 	a = kmalloc(...);
> 	b = kmalloc(...);
> 
> 	if (!a || !b)
> 		goto out;
> 
> 	...
> 
> out:
> 	kfree(a);
> 	kfree(b);
> }
> 
> to something else, accepted?

It seems that this case did not happen for me so far if you are looking
for this exact source code search pattern.

Variants of the current pattern were occasionally discussed a bit.


> I went checking and I haven't found such a patch.

A few similar update suggestions are still in development waiting queues.


> Did you understand my question?

Partly. - My interpretation of similar changes was eventually too broad
in my previous answer.


>> It is really needed to clarify the corresponding software development
>> history any further?
> 
> It is relevant because you are submitting a patch and your changelog
> implies that it makes the code follow some code structure rule that
> needs to be applied to the kernel.

I am proposing a change which was described also around various other
functions in some software already.


> As the above is a recurring pattern in kernel code, it is legitimate
> to ask if such a rule exist, and has been enforced before, or you are
> making it up.

I got the impression that special software development habits can also
evolve over time.


> As a proposer of a new pattern, what is the evidence you can bring to
> the discussion that supports that your solution is better?

I am trying to increase the software development attention on error
detection and corresponding exception handling at various places.


> What is the metric you are using to define "better"?

Do response times for system failures matter here?

Regards,
Markus

  reply	other threads:[~2016-12-12 22:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-10 20:45 [PATCH 0/4] [media] bt8xx: Fine-tuning for three functions SF Markus Elfring
2016-12-10 20:48 ` [PATCH 1/4] [media] bt8xx: One function call less in bttv_input_init() after error detection SF Markus Elfring
2016-12-10 21:29   ` Daniele Nicolodi
2016-12-10 22:10     ` SF Markus Elfring
2016-12-11 21:52       ` Daniele Nicolodi
2016-12-12  7:33         ` SF Markus Elfring
2016-12-12  7:39           ` Daniele Nicolodi
2016-12-12 17:15             ` SF Markus Elfring
2016-12-12 17:56               ` Daniele Nicolodi
2016-12-12 18:03             ` Clarification for acceptance statistics? SF Markus Elfring
2016-12-12 21:02               ` Daniele Nicolodi
2016-12-12 22:11                 ` SF Markus Elfring [this message]
2016-12-12 23:19                   ` Daniele Nicolodi
2016-12-12 19:11             ` [media] bt8xx: One function call less in bttv_input_init() after error detection Dan Carpenter
2016-12-10 20:50 ` [PATCH 2/4] [media] bt8xx: Delete two error messages for a failed memory allocation SF Markus Elfring
2016-12-10 20:51 ` [PATCH 3/4] [media] bt8xx: Delete unnecessary variable initialisations in ca_send_message() SF Markus Elfring
2016-12-10 20:53 ` [PATCH 4/4] [media] bt8xx: Less function calls in dst_ca_ioctl() after error detection SF Markus Elfring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dc59427b-5631-b7e7-e9e9-80e786a8c2d6@users.sourceforge.net \
    --to=elfring@users.sourceforge.net \
    --cc=daniele@grinta.net \
    --cc=hans.verkuil@cisco.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=khoroshilov@ispras.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).