Re: [PATCH 3/6] Input: Update vmmouse.c to use the common VMW_PORT macros

[Greg Kroah-Hartman]

On Tue, Dec 01, 2015 at 02:54:20PM -0800, Sinclair Yeh wrote:
> Hi,
> 
> On Tue, Dec 01, 2015 at 02:45:27PM -0800, Dmitry Torokhov wrote:
> > On Tue, Dec 1, 2015 at 2:32 PM, Sinclair Yeh <syeh@xxxxxxxxxx> wrote:
> > > Hi,
> > >
> 
> <snip>
> 
> > >> >   */
> > >> > -#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)      \
> > >> > -({                                                 \
> > >> > -   unsigned long __dummy1, __dummy2;               \
> > >> > -   __asm__ __volatile__ ("inl %%dx" :              \
> > >> > -           "=a"(out1),                             \
> > >> > -           "=b"(out2),                             \
> > >> > -           "=c"(out3),                             \
> > >> > -           "=d"(out4),                             \
> > >> > -           "=S"(__dummy1),                         \
> > >> > -           "=D"(__dummy2) :                        \
> > >> > -           "a"(VMMOUSE_PROTO_MAGIC),               \
> > >> > -           "b"(in1),                               \
> > >> > -           "c"(VMMOUSE_PROTO_CMD_##cmd),           \
> > >> > -           "d"(VMMOUSE_PROTO_PORT) :               \
> > >> > -           "memory");                              \
> > >> > +#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)                 \
> > >> > +({                                                            \
> > >> > +   unsigned long __dummy1 = 0, __dummy2 = 0;                  \
> > >>
> > >> Why do we need to initialize dummies?
> > >
> > > Because for some commands those parameters to VMW_PORT() can be both
> > > input and outout.
> > 
> > The vmmouse commands do not use them as input though, so it seems we
> > are simply wasting CPU cycles setting them to 0 just because we are
> > using the new VMW_PORT here. Why do we need to switch? What is the
> > benefit of doing this?
> 
> There are two reasons.  One is to make the code more readable and
> maintainable.  Rather than having mostly similar inline assembly
> code sprinkled across multiple modules, we can just use the macros
> and document that.

But the macro is only used here, and the variables aren't used at all,
so it makes no sense in this file.

> The second reason is this organization makes some on-going future
> development easier.

We don't plan for "future" development other than a single patch series,
as we have no idea what that development is, nor if it will really
happen.  You can always change this file later if you need to, nothing
is keeping that from happening.

thanks,

greg k-h
--
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/