[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yh8ia7nJNN7ISR1l@kroah.com>
Date: Wed, 2 Mar 2022 08:53:15 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Wei Liu <wei.liu@...nel.org>
Cc: Iouri Tarassov <iourit@...ux.microsoft.com>, kys@...rosoft.com,
haiyangz@...rosoft.com, sthemmin@...rosoft.com,
linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
spronovo@...rosoft.com, spronovo@...ux.microsoft.com
Subject: Re: [PATCH v3 02/30] drivers: hv: dxgkrnl: Driver initialization and
loading
On Tue, Mar 01, 2022 at 10:23:21PM +0000, Wei Liu wrote:
> > > +struct dxgglobal *dxgglobal;
> >
> > No, make this per-device, NEVER have a single device for your driver.
> > The Linux driver model makes it harder to do it this way than to do it
> > correctly. Do it correctly please and have no global structures like
> > this.
> >
>
> This may not be as big an issue as you thought. The device discovery is
> still done via the normal VMBus probing routine. For all intents and
> purposes the dxgglobal structure can be broken down into per device
> fields and a global structure which contains the protocol versioning
> information -- my understanding is there will always be a global
> structure to hold information related to the backend, regardless of how
> many devices there are.
Then that is wrong and needs to be fixed. Drivers should almost never
have any global data, that is not how Linux drivers work. What happens
when you get a second device in your system for this? Major rework
would have to happen and the code will break. Handle that all now as it
takes less work to make this per-device than it does to have a global
variable.
> I definitely think splitting is doable, but I also understand why Iouri
> does not want to do it _now_ given there is no such a model for multiple
> devices yet, so anything we put into the per-device structure could be
> incomplete and it requires further changing when such a model arrives
> later.
>
> Iouri, please correct me if I have the wrong mental model here.
>
> All in all, I hope this is not going to be a deal breaker for the
> acceptance of this driver.
For my reviews, yes it will be.
Again, it should be easier to keep things in a per-device state than
not as the proper lifetime rules and the like are automatically handled
for you. If you have global data, you have to manage that all on your
own and it is _MUCH_ harder to review that you got it correct.
Please fix, it will make your life easier as well.
thanks,
greg k-h
Powered by blists - more mailing lists