[PATCH V13 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
Jason Wang
jasowang at redhat.com
Tue Nov 19 03:03:39 UTC 2019
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
>
More information about the dri-devel
mailing list