Re: [PATCH V13 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework

[Jason Wang <jasowang@redhat.com>]

On 2019/11/18 下午11:17, Greg KH wrote:
> On Mon, Nov 18, 2019 at 06:59:23PM +0800, Jason Wang wrote:
>> +static void mvnet_device_release(struct device *dev)
>> +{
>> +	dev_dbg(dev, "mvnet: released\n");
>> +}
> We used to have documentation in the kernel source tree that said that
> whenever anyone did this, I got to make fun of them.  Unfortunately that
> has been removed.
>
> Think about what you did right here.  You silenced a kernel runtime
> warning that said something like "ERROR! NO RELEASE FUNCTION FOUND!" by
> doing the above because "I am smarter than the kernel, I will silence it
> by putting an empty release function in there."
>
> {sigh}
>
> Did you ever think _why_ we took the time and effort to add that warning
> there?  It wasn't just so that people can circumvent it, it is to
> PREVENT A MAJOR BUG IN YOUR DESIGN!  We are trying to be nice here and
> give people a _chance_ to get things right instead of having you just
> live with a silent memory leak.
>
> After 13 versions of this series, basic things like this are still here?
> Who is reviewing this thing?


Apologize that static structure is used here, will fix them with dynamic 
one. I just borrow the codes from other vfio-mdev samples without too 
much thought here ...


>
> {ugh}
>
> Also, see the other conversations we are having about a "virtual" bus
> and devices.  I do not want to have two different ways of doing the same
> thing in the kernel at the same time please.  Please work together with
> the Intel developers to solve this in a unified way, as you both
> need/want the same thing here.


Sure, some functions looks similar, but the "virtual" bus does not 
contain a management interface and it's not clear that how it can be 
used by userspace driver. For this series, sysfs/GUID based management 
interface is reused and we had a concrete example of how it would be 
used by userspace driver[1] and a real hardware driver implementation[2].

[1] https://lkml.org/lkml/2019/11/7/62
[2] https://lkml.org/lkml/2019/11/12/215


>
> Neither this, nor the other proposal can be accepted until you all agree
> on the design and implementation.


Yes.

Thanks


>
> /me goes off to find a nice fruity drink with an umbrella.
>
> greg k-h
>