On 2022/11/29 21:15, Jason Gunthorpe wrote:
On Tue, Nov 29, 2022 at 10:02:46AM +0800, liulongfang wrote:
On 2022/11/28 21:39, Jason Gunthorpe wrote:
On Mon, Nov 28, 2022 at 11:11:56AM +0800, Longfang Liu wrote:
@@ -119,6 +132,9 @@ struct vfio_migration_ops { enum vfio_device_mig_state *curr_state); int (*migration_get_data_size)(struct vfio_device *device, unsigned long *stop_copy_length);
- int (*migration_get_data)(struct vfio_device *device, char *buffer);
- int (*migration_get_attr)(struct vfio_device *device, char *buffer);
- int (*migration_debug_operate)(struct vfio_device *device, unsigned int cmd);
Please don't do wrappers like this, give the variant driver a chance to create its own files natively under the debugfs directory
Using this public debugfs file does not need to deal with file creation and destruction. The driver only needs to define its debug operation command, isn't it simpler?
No, it is obfuscating the normal kernel apis, what if a driver wants two files?
Yes, if there are special devices that require multiple debugfs files and use the same operation, using this migration_debug_operate() will cause the function to be impossible.
Thanks, Longfang.
debugfs is not a heavy burden to implement files for.
Jason .