Re: [patch 00/24] lib/kobject: kset_create_and_add return error clean up

[Theodore Ts'o]

On Tue, Jun 17, 2014 at 10:25:30PM +0800, Jeff Liu wrote:
> Hello,
> 
> Currently, to verify if kset_create_and_add() is succeed or not, almost
> all subsystems with sysfs support are check up the return value against
> NULL, then return -ENOMEM on failure, since kset_create_and_add() always 
> return NULL in case of anything wrong.  However, kset_register() can fail
> due to other reasons, hence it's better to return the actual error on
> kset_create_and_add(), this patch series is just did that and this is
> inspired by Christoph in another thread:
> http://www.spinics.net/lists/linux-mm/msg74729.html

Number one, please, please, please use git send-email with
sendmail.chainreplyto set to true in your .gitconfig (which is the
default) or use --chain-reply-to.  Without reply chaining, it's
incredibly painful to find related patches, and these patches are very
clearly related.

Number two, for changes like this, my strong recommendation is to have
a single large patch that makes all of the change at once.  Breaking
up the commits into each individual patch just adds a lot of noise
into the system, and it also invites potential problems when people
find a single patch out of context, and might accidentally backport
the patch (which as described, sounds like it's a bug fix) without
realizing that it's actively harmful until you apply the first patch
in this patch series.

In additoin, when you make an API change like this, and then spread
out the changes across two dozen patches, it also breaks
bisectability, although in this case the chance that
kset_create_and_add would fail is relatively small.  It's the
principle of the thing, though.

For the ext4 portion of this patch set (which I think should be a
single patch):

Acked-by: Theodore Ts'o <tytso@xxxxxxx> 

	  	   			     - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/