RE: [PATCH V5 7/9] Drivers: hv: vmbus: add a mechanism to pass hvsock events to the hvsock driver

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

 



> From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx]
> > diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> >
> > +/* hvsock related definitions */
> > +enum hvsock_event {
> > +	/* The host application is close()-ing the connection */
> > +	HVSOCK_RESCIND_CHANNEL,
> > +};
> > +
> >  struct vmbus_channel {
> >  	/* Unique channel id */
> >  	int id;
> > @@ -740,6 +746,13 @@ struct vmbus_channel {
> >  	void (*sc_creation_callback)(struct vmbus_channel *new_sc);
> >
> >  	/*
> > +	 * hvsock event callback.
> > +	 * For now only 1 event is defined: HVSOCK_RESCIND_CHANNEL.
> > +	 */
> > +	void (*hvsock_event_callback)(struct vmbus_channel *channel,
> > +				      enum hvsock_event event);
> 
> Would it make sense to rename it to something more general,
> e.g. sc_rescind_callback and call it for all drivers (even if we don't
> need it now) intead of introducing enum hvsock_event? When new events
Your suggestion is good: channel->hvsock_event_callback != NULL implies
is_hvsock_channel(channel) is true.

> arrive we'll just add new callbacks (or, alternatively, we could unify
> it to 'channel_event_callback' and merging with sc_creation_callback()
> but I'd say it is uglier).

I'm OK to use the idea "when new events arrive we'll just add new callbacks".

Let me make a new patch.

Thanks,
-- Dexuan
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux