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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization



[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux