[PATCH 3/3] iphlpapi: Implement CancelIPChangeNotify.

Erich E. Hoover ehoover at mymail.mines.edu
Fri May 10 09:00:01 CDT 2013


On Fri, May 10, 2013 at 3:48 AM, Hans Leidekker <hans at codeweavers.com> wrote:
>
> On Wed, 2013-05-08 at 15:34 -0600, Erich E. Hoover wrote:
> > ...
> > +#ifdef NLMSG_OK
> > +# define WINE_LINKMON_FAMILY         PF_NETLINK
> > +# define WINE_LINKMON_TYPE           SOCK_RAW
> > +# define WINE_LINKMON_PROTO          NETLINK_ROUTE
> > +# define WINE_LINKMON_ADDRCHANGE(b)  (NLMSG_OK((struct nlmsghdr*)b, len) \
> > +             && (((struct nlmsghdr*)b)->nlmsg_type == RTM_NEWADDR \
> > +                 || ((struct nlmsghdr*)b)->nlmsg_type == RTM_DELADDR))
> > +#endif
>
> I don't see the need for these defines. WINE_LINKMON_ADDRCHANGE could be turned
> into a function.
>

For the reason you noted below, on Mac it would make sense to set
these defines to be PF_SYSTEM, SOCK_RAW, and SYSPROTO_EVENT
(respectively).  I wasn't sure whether the address change would be
better as a define or a function so I made it a define to fit with the
others, but I'd be happy to change it if you think it'd be better as a
function.  It also seems that on Mac one uses an ioctl() request
instead of bind() to finish setting up the socket, but I figured that
having that as another define (or function) would be a little bit much
for this patch.

> ...
> > +    SERVER_START_REQ( create_socket )
>
> Using a generic socket object might work I guess. The cost will be a new socket
> per caller whereas in theory we could serve all callers with a single socket,
> though that would require a dedicated server request. That might be needed anyway,
> if this handle somehow turns out to be special.

According to the documentation, the handle is soley for use in
GetOverlappedResult - so I think we should be ok with implementing
this with a generic socket for now.  I don't think it's worth the
effort to make a special server request just so that we can use a
single socket for this call, as it's only useful for each application
to open one of these handles (while you could create more than one
they will _all_ wakeup when the address list changes).  However, we
could always change things later if we discover that the handle has
special properties or if there's some application that has a lot of
these handles floating around.

> I know MacOS has a similar socket based mechanism that could probably be handled
> in the same way.

Just let me know what you think, thanks for taking the time to look this over!

Best,
Erich



More information about the wine-devel mailing list