Re: [PATCH v2 0/4] xen: prefer xenbus_scanf() over xenbus_gather()

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Jul 08, 2016 at 04:41:20PM +0100, David Vrabel wrote:
> On 08/07/16 15:17, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jul 08, 2016 at 06:21:52AM -0600, Jan Beulich wrote:
> >> For single items being collected this should be preferred as being more
> >> typesafe (as the compiler can check format string and to-be-written-to
> >> variable match) and more efficient (requiring one less parameter to be
> >> passed).
> >>
> >> 1: xenbus: prefer xenbus_scanf() over xenbus_gather()
> >> 2: xen-blkback: prefer xenbus_scanf() over xenbus_gather()
> >> 3: xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
> >> 4: xen-netback: prefer xenbus_scanf() over xenbus_gather()
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> ---
> >> v2: Avoid commit messages to continue from subjects. Group into a series.
> > 
> > To confuse this, Roger and I are the block sub-maintainers, which
> > when we are happy, I send to Jens, while the rest go through Boris,David, and Juergen.
> > 
> > Anyhow, I've already committed and tested for regressions these:
> > 79ef83a xen-blkback: constify instance of "struct attribute_group"
> > 5e4d659 xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
> > e9d1ebe xen-blkback: prefer xenbus_scanf() over xenbus_gather()
> > 5b3b1db xen-blkback: really don't leak mode property
> 
> If they're tree wide largely mechanical changes to Xen-related APIs I
> prefer that they go via the Xen tree all together.
> 
> This saves the submitter chasing the individual subsystem maintainers.

Sure, but from a stricly SubmittingPatches point of view it would
fall on your to get the Acks from the other maintainers.

Either way, I am OK with those blkback and blkfront going through
your tree, albeit one will conflict with Jens 'for-4.8/drivers'.

> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel